Manifest V3 builds
Extensions built for how Chrome works now — service workers, declarative permissions scoped tight, and state kept in storage so nothing dies when the worker sleeps.
We build Manifest V3 Chrome extensions — and we run two of our own in the Web Store: KeepChats, our Reddit power-suite, and Gwora, an AI co-pilot for Upwork freelancers. Every trap in this platform, we have already hit on our own products.
Manifest V3 killed the long-lived background page, so your worker is now killed and restarted whenever Chrome feels like it — and code that assumed a running process quietly falls over. That is only half the risk. The other half is never reaching users at all: over-broad permissions, a privacy policy that does not match what the extension does, or remotely-hosted code — any one of which gets the listing bounced at review. We build around both realities, and we know they hold up because our own two extensions ship on top of them every day.
Extensions built for how Chrome works now — service workers, declarative permissions scoped tight, and state kept in storage so nothing dies when the worker sleeps.
Content scripts that read and change the pages your users are on without clashing with the site, wired to the worker through reliable message passing — the part that breaks in careless extensions.
We handle the listing, permission justifications, privacy disclosures and the reviewer back-and-forth — scoping permissions tight so it clears review fast and users trust the install prompt.
We port dead Manifest V2 extensions to V3 — background page to service worker, deprecated APIs replaced, and tested so nothing silently breaks when the worker restarts.
When an extension does real work, most of it belongs on a back end you own — not in a client anyone can view-source. We build authenticated APIs, keep secrets and keys off the page, and handle login the way our own Gwora does, so AI and account features are not one inspect-panel away from abuse.
Chrome ships changes that break working extensions, and the Web Store keeps moving its policy. We stay on to update permissions, migrate off deprecated APIs, and get changes re-reviewed — so the extension is still running for your users six months in, not quietly dead after an update.
We map what it does on which pages, which permissions it truly needs, and where the Web Store will scrutinise it — with a fixed estimate before any code.
Working software each week loaded in a real browser, tested against the actual sites and the service-worker lifecycle — not just a happy-path demo.
We get it through Web Store review, hand over readable code your team can own, and are still here when Chrome changes something under you.
| Duskel | In-house | A freelancer | |
|---|---|---|---|
| Shipped-their-own experience | Two of our own MV3 extensions live in the Web Store — every trap already hit | Depends entirely on who you have and whether they have shipped one before | Maybe, maybe not — hard to verify past the portfolio screenshots |
| Service-worker lifecycle | Built around the worker sleeping and restarting — state kept in storage | A common first-timer trap; usually learned the hard way in production | Varies wildly; the classic source of "works on my machine" bugs |
| Web Store review | We handle listing, permission justifications and reviewer back-and-forth | Your team learns the review process on your timeline | Often handed back to you at submission — "that part is on you" |
| Manifest V3 | V3 only — how the platform works now, not the dead tutorials | Fine if current; a risk if they last touched extensions in the V2 era | Depends who you get; plenty still build the old way |
| Still there in six months | A studio that owns the outcome and is here when Chrome changes something | Yes — if the person who built it has not moved on | Frequently gone after handover, right when Chrome shifts under you |
A focused single-purpose tool — a content script, a popup, one clear job on the pages your users are on — built on MV3 and taken through Web Store review.
Auth, a back end, AI features, multiple content scripts and cross-site behaviour — the kind of extension our own Gwora is. Built for the service-worker lifecycle, not against it.
Porting a dead Manifest V2 extension to V3 — background page to service worker, deprecated APIs replaced, tested so nothing silently breaks, then back through review. Priced on how much assumed a long-lived process.
Typical ranges, not a fixed menu — permissions and Web Store review shape the real scope. You get a fixed quote before a line of code.
Both — and the first matters more. We build and ship two of our own Manifest V3 extensions: KeepChats, our Reddit power-suite, and Gwora, an AI co-pilot for Upwork freelancers. Every problem you will hit — service worker lifecycles, Web Store review, content-script clashes — we have already hit in production on our own dime.
Only V3 — V2 is dead and Chrome is removing it. That means service workers instead of background pages, declarative permissions, and the message-passing patterns that keep an ephemeral worker from dropping state. It is a real shift, and a lot of tutorials still teach the old way. We build for how the platform works now.
Yes, and it is more than a config change. The background page becomes a service worker that Chrome kills and restarts, so any code that assumed a long-lived process has to be reworked around events and storage. We port the logic, replace the deprecated APIs, and test that nothing silently breaks when the worker sleeps — then get it back through review.
We handle it — the listing, the permission justifications, the privacy disclosures, and the back-and-forth if a reviewer pushes back. The common rejection is asking for broad permissions you do not need, so we scope permissions tight from the start. That is faster through review and it is what users trust when they read the install prompt.
Edge runs the same Chromium extension almost as-is, so that is nearly free. Firefox uses a compatible but not identical WebExtensions API, so a cross-browser build takes deliberate work — we tell you upfront what shares code and what needs a separate path, instead of promising "write once, run everywhere" and quietly breaking on one.
Usually a few days, sometimes hours, occasionally a week or two if a reviewer flags something. The single biggest delay is over-broad permissions, so we scope permissions tight from the start and write the justifications clearly — which is both faster through review and what users trust when they read the install prompt. We handle the back-and-forth if a reviewer pushes back, rather than handing it to you.
Asking for more permissions than the extension visibly needs is the classic one — reviewers want to see why each is used. After that: a privacy policy that does not match what the extension does, unclear or misleading listing copy, remotely-hosted code that violates the policy, and functionality the reviewer cannot actually reach to test. We build with each of these in mind, because we have been through the review on our own extensions.
For practical purposes it has already passed — Chrome has been disabling Manifest V2 extensions, and the Web Store no longer accepts them. If you are still on V2, you are on borrowed time: the extension can stop running for your users with a Chrome update. Migrating to V3 is not optional maintenance anymore, it is keeping the extension alive, and it is real work because the service-worker model changes how the whole thing runs.
By assuming it will die — because it will. Manifest V3 kills and restarts the worker whenever Chrome decides, so we keep no state in memory that matters, persist everything to storage, and drive the extension off events rather than a running loop. Long tasks are structured to survive a restart, and we test against the worker actually sleeping, not just the happy path where it happens to stay awake. That single discipline is where most flaky-extension bugs come from.
Tell us what it should do on the page. We will scope a Manifest V3 extension built by people who ship their own.
We build software worth keeping — for clients, and for ourselves.
Founded & led by codewithumar