Browser extensions as AI app distribution

If you spend an afternoon looking at where AI features actually live in 2026, you notice something uncomfortable. The genuinely useful ones are not new apps. They are not new tabs. They are not Slack bots. They are quiet additions to the surfaces people already stare at all day: their inbox, their Linear board, their Notion page, their Sheets tab, their pull request, their internal admin tool. That observation does not even rise to the level of insight anymore — it is just what shipped.

What is interesting is that “live where the user already is” is also a description of a browser extension. Extensions are not new. They are unfashionable. They are mildly annoying to publish. The store review process is slow. And yet, for a particular shape of AI feature, an extension is one of the best-shaped distribution channels in software.

This is the case for treating extensions as a first-class AI distribution surface — and a quick walk through what Anouk is built to do about it.

The user is already there

The first underrated thing about an extension is that the user is already in the right place. They opened Gmail because they want to deal with email. They opened a PR because they want to deal with the PR. They opened LinkedIn because they want to deal with LinkedIn, or at least pretend to. You do not need to teach them where to find your tool, because your tool is sitting on the page they were already going to load.

Compare that to a standalone AI app. The standalone app is “open a new tab, paste the thing, ask the model, copy the answer back.” That is six interactions where there could be one. Half the AI features you have seen in the wild would not need to exist as their own product if they were a button on the surface they augment.

The browser extension is a way to ride along on a context the user has already established. The page is loaded, the cookies are set, the DOM is populated. From inside a content script, the relevant text is one document.querySelector away. That is a huge head start.

The context is already structured

The second underrated thing is that the content you would want to feed to a model is already, roughly, formatted. The web has spent twenty-five years making HTML expressive enough that an email’s subject line lives in a recognizable place, a PR’s diff is in a recognizable place, a Google Doc’s selected text is sitting in a known DOM range. You do not have to wire up an OCR pipeline or scrape a PDF. You can grab the structured DOM and pass the relevant slice to the model.

This is why a five-line content script can do what a five-thousand-line web app can do for the same task. The web app has to convince the user to copy the content over. The extension just reads it.

Anouk leans on this directly. The AIService is designed to be called from inside a content script with a chunk of context and an instruction. You don’t build a request pipeline; you write a function that says “given this email body, summarize the action items.”

BYO model is a feature, not a tax

The third underrated property is more recent. As of 2026, a sizable chunk of the audience for AI features already has their own provider account — OpenAI, Anthropic, or a local Ollama box. They are also reasonably twitchy about handing that key to a third-party SaaS, especially one whose privacy policy reads like it was written by a chatbot. They would happily run an extension that talks to their own provider directly.

An extension is the cleanest possible surface for that. There is no backend in between. The user’s content goes from the page, through your extension’s content script, to the provider they chose, and back. You, the developer, do not see the content. You do not see the key. You do not have to host inference. You do not have to absorb the bill when a usage spike happens.

This is what Anouk is built to enable. The settings panel is part of the framework precisely because BYO provider is part of the model. The user opens the panel, pastes a provider URL, pastes a key, picks a model, and they’re running. You ship one bundle; ten thousand users run it against the provider of their choice.

For the “indie dev shipping a useful tool on weekends” market, this is the right architecture by miles. It collapses the operating expense to zero, removes the regulatory surface area, and ships the privacy story for free.

The Chrome store is not the bottleneck people think it is

A standard objection to “ship as an extension” is the store review process. Yes, the Chrome Web Store review is real, and yes, it can stretch into weeks if you trigger one of the more sensitive permission patterns (the manifest’s host_permissions field is the usual culprit). But two things have shifted.

First, Manifest V3 has been the standard long enough that the review heuristics are stabler than they used to be. If you keep your host_permissions tight (which Anouk’s default scaffold does — it explicitly enumerates only the provider URLs you actually call), reviews are quick.

Second, the bar to load an unpacked extension for your own testing is zero. You build, you toggle developer mode in chrome://extensions, you load the directory, you iterate. Anouk’s CLI gets you to a buildable unpacked extension in one command. The path from “idea” to “loaded extension I’m using” is shorter than the path to “deployed Next.js app I’m using.” The path to “in the store” is longer, but the path to “in your own browser” is instant.

Where this breaks down

It would be dishonest to pitch extensions as the right answer to everything. There are clear cases where they are not.

If your AI feature needs aggressive cross-session memory, an account model, multi-user collaboration, or a billing flow, you are building a web app and an extension is, at best, the front door. If your feature is fundamentally about ingesting content that lives outside the browser (your terminal, a file on disk, the Figma desktop app), the extension is the wrong surface.

If your feature needs a server-mediated guardrail — content filtering before the user sees the model’s output, for instance, or a per-organization rate-limit — you cannot do that entirely client-side, and the extension is going to need to talk to something you host. At that point you might as well be a web app with an extension front-end.

And finally, if your feature ships to a browser where Manifest V3 is not the story (Safari has its own variant; Firefox’s quirks are well documented), you need a build tool that targets all of them. Anouk’s templates target Chromium-style MV3 today. If multi-browser is critical, pair Anouk with a framework like Plasmo or WXT for the build side and let Anouk handle the AI side.

What the framework is for

Anouk does not exist because “build an AI extension” is unsolved. It is, in the cumulative sense, very solved — you can hand-roll all of it in an afternoon. Anouk exists because that afternoon is the same afternoon every time. Wire fetch. Wire cache. Wire queue. Wire settings. Wire manifest. Wire CSP. By the time you are done, the user is no closer to using your feature than they were six hours ago.

anouk init collapses that afternoon to a cd and a npm run build. From there you are building the part that is actually new. That is the entire pitch: not “we made the AI better” but “we removed the part that wasn’t your product.” For a category as distribution-rich as browser extensions, that is most of what was holding the category back.