Most people asking what a Chrome extension costs are picturing the wrong thing. They imagine the toolbar icon and the little popup, and those are genuinely cheap. What they are not picturing is the part that costs money: the permissions the extension needs, the server it talks to, the way it survives a page reload, and the review process that decides whether any of it reaches a user. That is where a quote goes from one thousand dollars to twenty.
So rather than give you a single number that would be a lie, here is how the price actually gets assembled, what pushes it up, and roughly where the tiers land. Duskel builds extensions from around $1k for a genuinely simple one, with anything involving a back end, AI, or cross-browser support climbing from there.
What actually drives the price
The first driver is what the extension is allowed to touch. An extension that restyles the page you are on needs almost nothing. An extension that reads content across every site, injects scripts into other people's pages, intercepts network requests, or reaches into your tabs and history needs broad permissions, and every one of those permissions is more code, more edge cases, and more scrutiny at review time. Permissions are the single biggest hidden cost, because a scary permission list gets your submission held for manual review.
The second is whether there is a back end. An extension that lives entirely in the browser is a fixed, bounded piece of work. The moment it needs accounts, saved data, syncing across devices, a licence check, or an API it calls, you are no longer building an extension — you are building an extension plus a server, and the server is usually the larger half. Authentication, a database, and hosting do not care that the front end happens to be a browser extension.
The third is AI. If the extension summarises the page, rewrites text, answers questions, or does anything with a model, you are paying for prompt design, a proxy so your API key is not sitting in shipped code, rate limiting so one user cannot run up your bill, and handling for when the model is slow or wrong. AI features are rarely the hard part to prototype and always the part that needs the most hardening before real users touch it.
Cross-browser is a multiplier, not an afterthought
"Can it also work in Firefox and Edge?" sounds like a small ask and is not. Edge is close to Chrome and usually cheap. Firefox uses a different extension model in places, has its own review process, and has genuine API differences that mean testing and fixing the same feature twice. Safari is another world entirely — it wants a wrapped app, an Apple developer account, and its own submission. Each additional browser is roughly its own smaller project bolted onto the first, so decide up front which ones you actually need rather than discovering the cost after launch.
The honest default is to build for Chrome first, ship it, see whether anyone asks for the others, and only then pay for them. Building for four browsers on day one is a common way to spend money on reach you do not have yet.
The cost tiers, honestly
Simple, from around $1k: one job, one browser, no server. A tool that formats a page, adds a button somewhere useful, blocks something, or exposes a small utility in a popup. State lives in the browser, there is no login, and the permission list is short enough that Web Store review is fast. This is a few days of work and it is the tier most "I just wish Chrome could do X" ideas actually sit at.
Full-featured, $5k and up: accounts, a back end, saved and synced data, maybe AI, maybe content scripts running across many sites. This is the tier where the extension is the visible tip of a real product. The number depends almost entirely on how much server there is behind it, because that is where the engineering time goes. Most serious business extensions live here.
Migration and rescue, priced case by case: you have an existing extension that broke, got pulled from the store, or is stuck on the old Manifest V2 and needs to move to V3. This is not a from-scratch build, but it is not free either — it is untangling someone else's code, understanding what it was allowed to do, and rebuilding the parts the platform no longer permits. We scope these individually because the cost is entirely about the state of what already exists.
What is cheap and what is expensive
Cheap: the visible UI, popups, options pages, restyling a site, single-purpose tools, and anything that keeps its data in the browser. If your idea fits in the popup and touches only the current tab, you are on the affordable end and should not be quoted otherwise.
Expensive: broad permissions across all sites, a back end with accounts and syncing, AI that needs a proxy and rate limits, cross-browser support, and Web Store review for anything that looks like it could read a lot of user data. None of these are exotic, but each one turns a bounded job into an open-ended one, and a good quote tells you which of them your idea actually needs instead of pricing for all of them by default.
The way to spend the least is to be ruthless about the first version. Ship the one feature that proves people want it, in one browser, with the narrowest permissions that make it work. You can always add the server, the sync, and the second browser once real usage tells you they are worth paying for.