The browser extension development company that handles the store review, not just the code.

Manifest V3 is the current extension platform across Chrome, Edge, and Firefox. Manifest V2 is being retired, Chrome stopped accepting new MV2 submissions in 2024 and is phasing out existing MV2 extensions through 2025-2026. The difference is architectural, not cosmetic. MV2 used long-running background pages that stayed in memory the whole time the browser was running. MV3 replaces those with service workers that the browser starts and stops on demand, which means any state you used to hold in a background page now has to live in storage (chrome.storage.local or session). MV2 used blocking webRequest listeners that could rewrite or cancel network requests in real time. MV3 replaces that with declarativeNetRequest, a declarative rules engine where you register the rules ahead of time and the browser enforces them, which is faster and more private but stricter about what you can do. If your extension was built on MV2, the migration isn't a config change, it's a rewrite of the background logic, the network interception layer, and often the storage model. We build new extensions on MV3 from day one and migrate MV2 extensions to MV3 as a scoped project rather than a quick patch.

One codebase, multiple browsers, with the smallest possible per-browser delta. Chrome, Edge, and Firefox all consume Manifest V3 with the WebExtensions API, so the same content scripts, service worker, and popup UI run across the three with minor manifest differences. Edge accepts a Chrome build almost verbatim. Firefox needs a small number of API substitutions (browser.* vs chrome.* namespace, polyfilled via webextension-polyfill) and slightly different permission declarations. Safari is the outlier. Safari Web Extensions ship as macOS or iOS apps via Xcode, with the WebExtensions code wrapped in a native Swift shell, and they require an Apple Developer Program membership for distribution through the Mac App Store and iOS App Store. We build the core extension logic once in TypeScript, share content scripts and the popup UI across all four browsers, and maintain per-browser manifest files and the Safari Xcode wrapper as the only platform-specific pieces. That keeps maintenance cost down as the product evolves.

The review process has two stages. The automated scan checks for malware signatures, banned API usage, and obvious policy violations. The human review reads your store listing, tests the extension in a clean Chrome profile, and checks that the extension does what the listing says it does, with the permissions it requests, and no more. Reviews typically take 1-3 business days for established developer accounts and 1-3 weeks for new accounts on first submission. The most common rejection reasons we see and resolve are: requested permissions that aren't justified by the described functionality (asking for host_permissions on all_urls when the extension only needs to run on one site), a privacy policy that doesn't match what the extension actually does with user data, a single-purpose violation where the extension tries to bundle several unrelated features, remotely hosted code being executed (MV3 prohibits this, all code must ship in the package), and store listing screenshots or descriptions that overpromise what the extension does. When an extension is rejected, the rejection email cites the specific policy section. We know what each policy section means in practice, from shipping our own extension through review and staying current with store policy, and we revise the submission to pass on the next round, usually within 48 hours of the original rejection.

A focused single-browser extension, one core feature, popup UI, content scripts, and Chrome Web Store submission, typically runs $15,000-$35,000. Cross-browser builds (Chrome, Edge, Firefox from one codebase) add roughly 15-25%. Adding Safari Web Extensions (which requires the Xcode native shell and Apple Developer Program distribution) adds another $8,000-$15,000 on top. Extensions with backend services (AI assistants calling LLM APIs, CRM extensions syncing with Salesforce or HubSpot, sales tools with their own data layer) are scoped including the backend. We give you a fixed cost before any code is written, not a time-and-materials estimate.

Most extensions reach a store-ready v1 in 6-12 weeks from project start, then grow from there. A focused single-purpose extension on one browser can ship in 4-6 weeks. Cross-browser extensions with backend services typically run 10-14 weeks. The Chrome Web Store review adds 1-3 days for established developer accounts and 1-3 weeks for first-time submissions, which we factor into the launch date rather than treating it as an afterthought. We start with a 1-week discovery to confirm the permission model and the Manifest V3 architecture before writing application code, because a misjudged permission scope is the most common reason extensions get rejected or have to be rebuilt mid-project.

Yes. We sign NDAs before discovery calls for projects that involve proprietary workflows, internal tooling, or competitive product ideas. Full source code ownership transfers to you at project completion. We do not retain rights to use your extension or its underlying logic in other projects.