Browser Extension Development: A Guide for Founders

A browser extension is one of the few products that lives exactly where your users already work. No new tab to remember, no app to open: it sits next to the address bar and acts on the page in front of them. Browser extension development looks small from the outside, and the code often is, but the parts that decide whether an extension ships on time are permissions, store review and the constraints of Manifest V3, not the feature itself.

We ship extensions ourselves. TabFold and SyncDock Client are live on the Chrome Web Store, built by the same team that builds client work, and our SyncDock, GuestDock and AuthDock plugins are published on WordPress.org. This guide is what I would tell a founder on a first call: when an extension is the right product, what building one actually involves in 2026, what review is like, and where a WordPress plugin is the better answer. If you want the short version of how we take these on, it is on our app development service page.

When an extension is the right product, and when it isn't

Extensions are brilliant at one thing: acting on pages the user is already visiting. Saving, clipping, annotating, filling, summarising, blocking, reorganising tabs. If your idea starts with "while the user is on some other site, we...", an extension is probably the natural shape.

They are a poor fit when the core of the product is a workspace people come to on purpose, when you need heavy background processing, or when most of your users are on mobile, where desktop-style extensions barely exist. In those cases the extension, if you build one at all, is a companion to the real product rather than the product.

Here is the comparison I use when a founder is not sure which shape they are building.

That last row is the most common one we see. A SaaS product with a working web app wants a "send this to us" button on other sites. The right build keeps the extension thin and puts the logic behind your API, which matters a lot once you see how updates and review work.

What Manifest V3 changes about how you build

Chrome extensions are now built on Manifest V3, and it shapes the architecture more than most first-time builders expect. The official Chrome extensions documentation is the reference, but the practical consequences are these.

The background is a service worker, and it goes to sleep. There is no long-lived background page holding state in memory. The worker wakes up for an event, handles it and can be shut down. Anything you need to remember goes into extension storage, not a variable. Code written as if the background never stops will work in testing and fail for real users in confusing, intermittent ways.

Your code ships in the package. Manifest V3 does not allow an extension to download and execute remotely hosted code. Every change to extension logic is a new version that goes through store review. This is the main reason to keep an extension thin: logic that lives behind your API can change today, while logic inside the extension changes on the store's schedule.

Content scripts live in their own world. Scripts injected into a page share its DOM but not its JavaScript. They are also running on sites you do not control, which redesign without warning. Selectors that depend on a third-party site's class names will break, and a good extension is written to fail gracefully when they do.

Network changes are declarative. Extensions that block or modify requests describe rules for the browser to apply, rather than intercepting every request in code. That is better for users' privacy and performance, and it limits some designs that were possible before.

Permissions are a product decision

Every permission your extension asks for either appears as a warning at install or needs justifying to the store, and usually both. "Read and change all your data on all websites" is a sentence that makes a careful user close the tab, and it is the kind of request that draws closer attention in review.

So we design for the smallest permission set that does the job. If the extension only needs to act when the user clicks it, it can often work on the active tab alone rather than every site. If a feature is only used by some people, its permission can be optional and requested at the moment it is needed, with context, rather than at install. Host permissions get scoped to the domains the product actually touches.

Chrome Web Store review, practically

Publishing means a developer account, a listing and a review. The parts that tend to catch teams out:

• A single, clear purpose. The store expects an extension to do one thing that a user can understand from the listing. A grab-bag of unrelated tools is a review problem and a marketing problem.
• A justification for each permission. The developer dashboard asks why you need each one. "For functionality" is not an answer.
• A privacy policy and honest data disclosures if the extension handles user data, which most useful ones do.
• A listing that matches the product. Screenshots, a description and, if you have one, a promo video. Claims in the listing have to be true of the version being reviewed.

Review time varies, and first submissions with broad host permissions tend to take longer. Never set a public launch date that depends on an approval landing the same day. Submit early, with the launch assets ready to go when it clears.

Beyond Chrome: Edge, Firefox and Safari

Edge is Chromium-based with its own add-ons store, so a well-built Chrome extension usually carries over with a separate listing. Firefox supports the same WebExtensions model with some API differences, so it needs testing rather than a straight upload. Safari is the outlier: extensions are packaged through Apple's tooling and distributed via the App Store. If you need more than Chrome, say so at the spec stage; retrofitting it later costs more.

Where WordPress plugins are similar, and where they are not

Plugins and extensions look like cousins: small, installable, reviewed by a directory. The review culture is different. The WordPress.org directory cares about licensing that is compatible with the GPL, human-readable code, security basics such as sanitising input and escaping output, and not tracking users without their consent. It also has firm rules on how a free plugin may promote a paid upgrade.

The bigger engineering difference is the environment. An extension runs in a handful of known browsers; a plugin runs on countless hosting setups, PHP versions, themes and other plugins you will never see, so many plugin bugs are conflicts rather than logic errors. We write plugin PHP to WordPress coding standards and test against that messiness. If you are marketing a plugin rather than building one, our guide to WordPress plugin video covers the listing side.

A scenario: the companion extension

Picture a small SaaS team with a research tool. Users save articles into the web app today by copying links, and the most common feature request is "let me save from the page I'm on." A two-week side project, someone says.

Here is how that plays out when it is scoped properly. The extension needs a login that shares the user's existing session, a button that captures the current page, and a way to show that the save worked. The capture logic, parsing and storage all belong in the web app's API, not the extension, so the team can improve them without resubmitting. The extension needs the active tab and a connection to one domain, nothing more. The listing needs screenshots, a privacy policy and a clear single purpose. And somebody has to decide what happens when the user is logged out, offline, or on a page the parser does not understand.

None of that is hard. All of it is easy to discover late, which is what a written spec is for.

Who should hire someone for this, and who shouldn't

Hire help if the extension is part of a real product with a roadmap, if nobody on your team has taken one through review, or if you need it and its launch video ready on the same day. Build it yourself if it is a weekend experiment or an internal tool, or if you already have a frontend engineer who has shipped extensions.

How we build extensions and plugins

Our app development process is the same for extensions, plugins and SaaS, with store-specific work at the end.

1. Discovery and a written spec. Journeys, data model, permission model, integrations and non-goals. You approve it before code exists, and nothing is quoted before it does.

2. Architecture and a working slice. One real journey working end to end, so architectural mistakes surface while they are cheap.

3. Reviewable increments. Builds you can install and use as they land, not status updates about them.

4. QA, security and store submission. Tests on the critical paths, a manual QA checklist, a security review of auth, permissions and data handling, then the submission: permission justifications, listing assets and the directory's standards.

5. Launch, handover and a support window. The repository with full Git history, documented environments, and the store listing in your name. You own the code outright, and a defect-fix window agreed at scoping covers the first stretch of real usage.

We use AI tooling through the build for scaffolding, tests and refactors, and we say so openly. Nothing merges without review by the engineer accountable for it, and anything touching authentication, permissions or user data is written or reviewed by a person.

Development is quoted per project, after the spec, because an extension and a multi-platform SaaS have nothing in common in scope. If you want the product and its launch marketing ready together, the Launch + Build package pairs a build with any of our fixed-price video kits, produced in parallel by the motion team. For what that launch video should contain, see our product launch video service.

Frequently asked questions

How long does it take to build a Chrome extension?

It depends heavily on scope, so we state it in writing after the spec rather than guessing. A focused, single-purpose extension is a much smaller job than one that syncs with a SaaS back end. Note that the 3 to 14 day figures on our packages page describe video kits, not software.

How long does Chrome Web Store review take?

It varies. Small updates to a narrowly scoped extension are often quick, while first submissions and extensions with broad permissions can take longer. Do not pin a public launch to a same-day approval.

Who owns the extension and the store listing?

You do. We transfer the repository with its full history, the documentation and the accounts, and the Chrome Web Store or WordPress.org listing is in your name. There is no licence-back and no runtime dependency on us.

Can you take over an extension or plugin another developer started?

Often, but we start with a paid audit rather than a quote: code health, dependencies, security and tests, with a written assessment of what to keep and what to rewrite. Sometimes that says a rebuild is cheaper.

The takeaway

An extension is the right product when your value happens on other people's pages. Keep it thin, put the logic behind your API, ask for the fewest permissions that work, and treat store review as a scheduled step rather than a formality. If your users live inside WordPress rather than a browser, a plugin is the better shape, with its own rules.

Our app development service sets out how we scope, build and hand over extensions, plugins and SaaS, and the WordPress industry page covers the plugin side. If you are earlier than that and planning a whole product, our SaaS MVP development and launch guide walks through the bigger picture. When you have an idea written down, tell us what the extension should do and we will send back the questions a spec needs to answer.