Inspiration

Every site blocker I'd used treated a domain as the unit of distraction — block Facebook entirely, or don't block it at all. That fell apart constantly for me, because the sites I needed to block weren't sites I never needed. A Marketplace listing, a client DM, a work thread — blocking the whole domain meant losing the one legitimate reason the tab was open, so I'd disable the blocker "just for five minutes" and the cycle would repeat. FocusRamp exists because I wanted a tool that understood the difference between a site and the specific feed on that site engineered to keep me scrolling.

What it does

FocusRamp is a Chrome extension that hides distracting social feeds — Facebook, Instagram, and X — instead of blocking the whole platform, so the parts you actually need (Messenger, Groups, a specific thread) stay usable. It also includes straightforward site blocking for the genuinely useless stuff, a built-in Pomodoro timer, and scheduled focus mode that turns itself on during set hours automatically. The core product is free forever with no account required.

How we built it

FocusRamp is a Manifest V3 Chrome extension built in vanilla JavaScript, HTML, and CSS — no framework overhead for something that needs to inject reliably into a page it doesn't control. Settings persist via the Chrome Storage API, and Pro sign-in uses chrome.identity.launchWebAuthFlow against Google OAuth, with the Pro backend API hosted on Vercel. Feed-hiding relies on MutationObserver to react to Facebook and Instagram's own DOM changes in real time, since neither site is a static page — content gets inserted, removed, and re-rendered continuously as you scroll and interact.

Challenges we ran into

The hardest bug wasn't in the initial feed-hiding logic — it was in keeping it working. Facebook's feed hiding stopped working after toggling an unrelated dark-mode-style CSS filter, and the root cause turned out to be a single cached DOM element reference going stale: Facebook's virtualized feed remounts its DOM node on repaint, and once that happens, anything holding onto the old reference silently stops affecting the page. The fix was to move from single-reference caching to a self-healing pattern — a Map of wrapper elements to their previous display state, re-scanned fresh on every mutation-observer tick instead of trusting a reference to still be valid. It's a small architectural change, but it's the difference between a feature that works once and one that keeps working as the page you don't control keeps changing under you.

What we learned

Building against a platform you don't control means designing for staleness by default — any reference to another site's DOM has an expiration date you can't predict, and the only reliable pattern is to re-verify rather than assume. That lesson ended up shaping how every DOM-dependent feature in FocusRamp is built, not just the one that first surfaced the problem.

What's next

More granular per-site feed controls, and continuing to harden the extension against the DOM changes social platforms ship regularly — since "keep working after the site changes" turned out to be the real, ongoing engineering problem, not a one-time fix.

Built With

Share this project:

Updates