Why I Stopped Fighting Chromium Extensions and Started Building What Actually Matters

When I started Kinka, the pitch to myself was simple. Take Chromium, strip the noise, add focus tooling, ship a better browser. Straightforward enough, until it wasn't.

The first few weeks were genuinely exciting. Getting a custom Chromium build running, tweaking the UI shell, removing the parts of the browser that have always annoyed me. It felt like real progress. Then I started working on extension support and everything slowed down.

The extension problem is nastier than it looks

Chromium's extension architecture is not something you just bolt onto a fork. The Manifest V3 transition alone introduced enough complexity to make my eyes water. Getting extensions to load reliably, handling permissions correctly, ensuring that the extension APIs you're exposing don't introduce security holes, it's an entire engineering discipline in itself. Google has whole teams working on this. I'm one person building in evenings and weekends.

The specific issues I kept hitting were around extension isolation and the way content scripts interact with the browser's internal page model. Some extensions worked fine. Others would silently fail, or worse, appear to work but produce incorrect behaviour that was extremely hard to diagnose. Every fix introduced new edge cases.

I spent a significant chunk of time on a permissions model that honestly still wasn't right by the time I stepped back from it. The deeper I went, the more it became clear that full extension compatibility wasn't a feature I could ship to a quality standard I was happy with. Not yet.

The decision to pull back

This wasn't an easy call. Extension support was part of the original vision for Kinka, the idea that you could bring your existing workflow over without friction. But I kept coming back to the same question: what is Kinka actually for?

The answer is focus. A browser that gets out of your way, protects your attention, and works reliably. Shipping a half-broken extension layer is the opposite of that. It would introduce unpredictability into the one thing Kinka is supposed to eliminate.

So I made the call to deprioritise extension support entirely for now and redirect that energy toward the core.

What I'm building instead

The area that's absorbed that effort is automation capture, and honestly it's become the most interesting part of the whole project.

The idea is that Kinka should be able to watch what you're doing and help you document, replay, or automate it without you having to set anything up. Native step capture built into the browser itself rather than layered on top as an extension. This is something that tools like Clickument gesture toward from the outside, but doing it natively opens up a completely different set of possibilities.

When the browser owns the capture layer, you get access to context that an extension never can, tab state, navigation events, form interactions, the full picture. The quality of what you can record and replay is in a different league.

I'm still in early stages on this but the direction feels right. It's the kind of feature that only makes sense in a purpose-built browser, which is the whole point of Kinka.

What this means for the roadmap

Extension support isn't dead. It's just not the priority right now. When Kinka's core is solid and the automation layer is something I'm genuinely proud of, revisiting extensions with a clearer scope will make more sense. Building a curated set of first-party integrations is probably a better approach than trying to support the entire Chrome Web Store anyway.

For now the focus is: fast, reliable, distraction-free, with native capture that actually works. Everything else follows from that.

If you're interested in following the build, I'll be writing more of these as Kinka develops. The messy, honest version of building a browser from scratch, not the polished retrospective.