How much does a Chrome extension cost to build?

A genuinely simple Chrome extension — one job, one browser, no server — costs around $1k–$3k and ships in about one to two weeks. A full Manifest V3 build with a back end, user accounts, AI, and a Web Store review to clear runs $5k–$20k or more over four to ten weeks. The gap between those two numbers is almost never the popup you are picturing. It is the permissions the extension needs, the server it talks to, and the review process that decides whether any of it reaches a user.

So rather than give you one number that would be a lie, here is how the price actually gets assembled, what pushes it up, and where the tiers land. Duskel builds Chrome extensions — and runs its own, so these ranges come from shipping real ones, not guessing.

What actually drives the cost

Most of the price is decided by a handful of variables. Before you ask anyone for a quote, know which of these your idea genuinely needs — because a good quote prices only the ones it does, and a lazy one prices for all of them by default.

• Permissions. An extension that restyles the current page needs almost nothing. One that reads content across every site, injects scripts into other people's pages, intercepts network requests, or reaches into tabs and history needs broad permissions — and every permission is more code, more edge cases, and more scrutiny. This is the biggest hidden cost: a scary permission list gets your submission held for manual review.
• A back end. The moment the extension needs accounts, saved data, cross-device sync, a licence check, or an API it calls, you are building an extension plus a server — and the server is usually the larger half. Auth, a database, and hosting do not care that the front end is a browser extension.
• Authentication. OAuth, session handling inside a service worker that Chrome kills on a whim, and secure token storage are their own line item. "Just let users log in" is rarely just anything in MV3.
• AI. Summarising, rewriting, or answering with a model means prompt design, a proxy so your API key is not shipped in the bundle, rate limiting so one user can't run up your bill, and graceful handling for when the model is slow or wrong. Cheap to prototype, expensive to harden.
• Web Store review. Anything that looks like it reads a lot of user data triggers manual review, a privacy policy, data-use disclosures, and sometimes a back-and-forth that adds days or weeks. Budget for the review, not just the build.
• Cross-browser support. Each additional browser is roughly its own smaller project. More on that below.
• Maintenance. Chrome ships updates, sites redesign and break your selectors, and MV3 policy keeps tightening. An extension is a living thing; a flat one-time price with no plan for upkeep is a quote that ends the day it ships.

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.

Specialist extension studio vs generalist freelancer

The other thing that moves the number is who you hire to build it. A generalist freelancer is cheaper by the hour and fine for a simple content-script tool. But MV3's service-worker lifecycle, message-passing quirks, storage races, and the Web Store review process are exactly where generalists lose weeks — and where a rejected submission or a silently-broken extension costs you far more than the day rate saved.

Why the specialist edge is real here

We do not just build extensions for clients — we ship and maintain our own. KeepChats is a live Chrome extension (a Reddit power-suite) and Gwora is an AI co-pilot extension for freelancers. That means the MV3 service-worker gotchas, the Web Store review process, secure auth inside an extension, and proxying AI calls so an API key never ships in the bundle are problems we have solved on software we personally depend on, not just billed for.

Practically, that shows up as fewer surprises: the permission list is scoped to survive review the first time, the service worker is treated as disposable so it doesn't fail silently for a third of your users, and the back end is built to the standard we hold our own products to. If you have an existing extension that broke or is stuck on Manifest V2, we scope migrations individually because the cost of a migration is entirely about the state of what already exists.

How to spend the least

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. State in the browser, no login, no server. That is the from-$1k tier, and it is where most "I just wish Chrome could do X" ideas actually belong.

Then let real usage tell you what to pay for next. Add the back end when people are saving things worth syncing. Add auth when there is an account worth protecting. Add the second browser when someone actually asks. Everything expensive — broad permissions, a server with accounts, AI behind a proxy, cross-browser support — turns a bounded job into an open-ended one, so add each only once it has earned its place.

FAQ

Have an extension idea and want a straight quote for it? Let us talk.

Send the problem. You get one fixed number and a plan back within a business day.