What wasn't working.
I had shipped Chrome extensions before, but always to a client spec. Build it, hand it over, and whether it is pleasant to use every day becomes someone else’s problem. My own feeds had become unusable. LinkedIn was recruiter engagement-bait and “humbled to announce” posts. X was crypto giveaways and a sidebar of trending topics I never found useful. Facebook kept showing me pages I had never followed. Every platform has a “not interested” button. I had clicked it hundreds of times. It trains a recommendation model, not a rule. I wanted a rule: block this keyword, block this author, highlight what I actually care about. So I built one.
What we actually did.
The first decision, made before any code, was that no feed data leaves the browser. Ever. This was not a marketing choice. It was a simple test: would I install this myself? A feed filter sees everything you read, so it had to run locally or not at all. The extension asks for one permission, storage. Everything is stored in chrome.storage.local. There is no server, so there is nothing to breach and nothing to be tempted to monetize later. One shared engine (background.js) decides HIDE, FOCUS, or PASS for any post. It knows nothing about the page layout. Three small adapters in content.js handle each platform. Each adapter answers four questions: where are the posts, what is the text, who is the author, and what is a stable ID for this post. Adding a new platform means writing one adapter. The matching logic stays the same.
Where the interesting calls were.
On day two, LinkedIn changed its layout and the adapter stopped finding any posts. LinkedIn and Facebook both use randomly generated CSS class names that change on every deploy, so code built against those names breaks often. The fix became the best lesson of the project: accessibility attributes are the one part of the page these platforms cannot hide, because breaking screen readers would break the law. Every adapter was rebuilt to use ARIA roles and labels instead. For example, LinkedIn’s own “Hide post by (Author)” button label is now used to detect the author, and it survives layout changes that break class-name matching. A second problem: all three feeds reuse and destroy elements as you scroll, so a post already marked as hidden could reappear as a “new” post when you scrolled back up. The fix was to identify each post by a stable ID (a link or component key, or a hash of the author and text as a fallback) instead of the page element, and cache each decision against that ID. Later, a spam pattern appeared using fake-bold Unicode characters to dodge plain-text keyword filters. This was fixed with one line of Unicode text normalization. Not every rule has a clean signal to match. A few toggles, such as detecting Facebook’s “Follow” or “Join” buttons, or LinkedIn’s “Promoted” label, rely on matching literal button text. This is fragile and will break if the site changes its wording or language. Each of these is commented in the code to explain why the shortcut exists and what would break it.
The numbers after we shipped.
The extension is live and free on the Chrome Web Store for X, LinkedIn, and Facebook. Three versions shipped in the first month (1.0, then 1.1, then 1.2). Each update came from a real gap found through daily personal use, not a backlog review: rule import and export, fake-bold spam detection, hiding Facebook group posts, hiding LinkedIn promoted posts, and a scoring system so one stray blocked word cannot hide a post that is otherwise clearly wanted. Adoption is still small, around 7 Chrome Web Store users, so the honest outcome so far is a working tool I use daily and a fast, self-directed way of improving it, not adoption numbers yet.
Things I'd carry into the next case.
The biggest difference from client work was not technical. It was speed of feedback. Every bug surfaced within a day, because I was using my own extension on my own feed, and I noticed problems a written spec would never have caught. The fake-bold spam bypass was not a bug report, it was me seeing a spam post that should have been blocked. A toolbar counter built in version 1.0 was removed in version 1.1 because I realized I never once looked at it, and there was no one to convince but myself. The lesson most useful beyond this project: when a platform hides its structure to stop you building against it, its accessibility layer is usually the one part it legally cannot hide. That is worth checking on any project that reads or automates another website, not just this one.