Half the Extensions We Are Asked to Build Should Be Something Else
An extension is a genuinely useful thing when the work happens on a web page you do not own. It is an expensive detour when the work happens on a page you do. We build Chrome, Edge and Firefox extensions for UK companies, and we spend the first conversation working out which of those two situations you are actually in.
Good Reason, Wrong Tool
These are real patterns of enquiry, generalised. In each case the underlying goal was sound and the extension was not the shortest route to it.
| What was asked for | Why an extension seemed right | What actually solves it |
|---|---|---|
| An extension so staff can reach our dashboard faster | It would put the product one click away | A better dashboard and a bookmark. An extension that only opens a URL adds an install step and a review process for nothing |
| An extension to scrape competitor prices overnight | The data is on a web page | A server-side job. Extensions only run while a browser is open with somebody logged in, which makes them a poor scheduler |
| An extension to stop staff visiting certain sites | It sits in the browser where the behaviour happens | Network or endpoint policy your IT team already owns. An extension a user can disable is not a control |
| An extension to store client records offline | It is always there in the browser | A web application with proper storage. Extension storage is small, per-profile, easy to lose and not somewhere business records should live |
| An extension so the tool works on phones too | Everything else is on the phone | A mobile or progressive web app. Chrome on Android has no extensions and Safari on iOS supports only a limited form |
| An extension to log time against whatever page is open | Only the browser knows what is open | This one genuinely is an extension, and we would build it |
Illustrative examples of enquiry patterns rather than named client projects.
What Nothing Else Can Do
An extension earns its place when it needs to see or change a page that belongs to somebody else, at the moment a person is looking at it.
Capture without retyping
A recruiter pulling a candidate off a job board into your applicant tracking system. A surveyor saving a planning application from a council portal. One click instead of eight fields copied by hand, with the source recorded.
Add context to a page you do not own
Your own credit status, contract terms or previous correspondence shown beside a company record on a third-party site. The user stays where they are working instead of holding two windows side by side.
Remove a repetitive sequence
Where staff perform the same eleven clicks in a supplier portal forty times a day. Automating a user-triggered sequence inside a system with no API is one of the highest-value things an extension does.
Internal tools for your own staff
Deployed by policy to managed machines rather than published publicly. No store listing, no marketing, no install funnel — just a small piece of software that removes a daily annoyance for eighty people.
A check at the moment of decision
Flagging that a supplier is not on the approved list, or that a document about to be uploaded contains something it should not, while the person is still on the page rather than in a report next month.
A second surface for an existing product
Where you already have a web application and customers spend their day somewhere else. The extension is a thin window onto your service, not a copy of it, and everything of value stays on your servers.
One Codebase, Three Sets of Paperwork
Chrome and Edge share an engine, so the code is mostly the same. The stores, the policies and the review queues are not.
Chrome and Edge
- Both Chromium, so one build covers them with only small differences
- Two separate developer accounts, two listings, two reviews, two sets of store assets
- Edge matters more in the UK than global figures suggest, because it is the default on managed Windows estates
- Both support force-installed enterprise deployment through Group Policy and Intune
- Chrome registration involves a small one-off developer fee; Edge does not charge one
- Practical approach: build for Chrome, submit to both, budget a little extra for the second listing rather than double
Firefox, and the Safari question
- Firefox uses the same WebExtensions model, so most code carries across with a manifest adjustment
- Background behaviour and a handful of APIs differ enough to need real testing rather than a quick check
- Firefox review can involve a human reading your source, which is a reason to keep the build reproducible and readable
- Firefox has an enterprise policy for managed deployment too, which matters in some public sector estates
- Safari is a separate project: the extension is wrapped inside a native macOS application, built with Xcode and submitted to the Mac App Store
- We quote Firefox as a modest increment and Safari as its own line, because that is what they cost
The Rules Extensions Now Live Under
Worth understanding whether you are commissioning a new extension or have inherited one that has stopped working.
The background is no longer always running
What used to be a permanently resident page is now a service worker that the browser stops when it is idle and restarts when something happens. Anything held only in memory disappears, so state belongs in storage or on your server. This is the single most common cause of an inherited extension behaving strangely.
No code fetched from your server
Everything that executes must be in the package the store reviewed. You can still fetch data, configuration and content, but not scripts. Extensions built around remotely loaded logic need restructuring rather than patching, and that is a rewrite in all but name.
Network rules are declared, not intercepted
Blocking or modifying requests is now done by declaring rules the browser enforces, rather than by inspecting every request in your own code. Better for privacy and speed, more constrained for anything that needed to make decisions dynamically.
Permissions can be granted later
Host access can be requested at the point it is first needed rather than demanded at install. It is more work to build and it materially improves how the install screen reads, which is usually a trade worth making.
If you have inherited an old extension
We audit it against the current rules first and tell you honestly whether it is a migration or a rebuild. Both answers happen, and the deciding factor is usually how much of the logic assumed a background page that never stopped.
The rules will change again
Extension platforms have shifted substantially twice in a decade and will shift again. We build with that assumed: keep the extension thin, keep the logic on your server where it is yours, and keep the surface that depends on browser APIs as small as it can be.
What the Warning Actually Says, and How to Make It Say Less
The install screen is the one piece of sales copy you cannot write. The browser generates it from the permissions in your manifest, and it does not soften anything. Ask for broad host access and a user considering your extension reads a sentence saying it can read and change all their data on every website they visit. A meaningful proportion of them stop there, and a corporate security reviewer stops harder.
Narrowing that sentence is real engineering work, and it is worth doing:
- Name the sites you actually need rather than requesting everything. Three named domains produce a far shorter and less alarming warning than a wildcard.
- Use the permission that applies only to the tab the user clicked on. For anything triggered deliberately by a person, this removes the broad-access warning entirely.
- Request the rest at the moment it is needed, with a sentence of your own explaining why, which is a much better place to make the case than a system dialogue.
- Drop permissions you stopped using. Manifests accumulate. An audit before every submission takes twenty minutes and regularly finds two that nothing references.
- Write the justification before you write the code. Both major stores ask you to justify each permission, and a permission you cannot justify in a sentence is usually one you should not be asking for.
- Expect the security questionnaire. A UK corporate buyer will ask what the extension can see, where data goes and whether you will sign a data processing agreement. A minimal permission set makes that a short conversation.
The commercial point is simple: permissions are the price of installation, and most extensions are asking for more than they spend.
Where Each Piece of the Code Actually Runs
An extension is three or four small programmes in different places that talk to each other. Knowing which is which explains most of what is easy and what is not.
Content scripts, inside the page
They can read and change what the user is looking at, and they are deliberately limited: no direct access to most extension capabilities, and a page that gets redesigned underneath them. Keep them small, defensive, and responsible only for reading and rendering.
The service worker, in the middle
Coordinates everything, talks to your API, holds the permissions. It starts when needed and stops when idle, so it cannot keep anything in memory between events, and long-running work has to be structured around that rather than fighting it.
The popup and options pages
Ordinary web pages that exist only while open. Useful for a quick action or a settings screen, and the wrong place for anything that has to happen reliably, because the moment the user clicks elsewhere they are gone.
Your API, where the product lives
Business rules, records and anything worth protecting belong on your server. The extension holds a token and a little cached state. This also means a change in rules ships without a store review, which is worth designing for deliberately.
Signing in without irritating anyone
If the user is already signed into your web application, the extension should pick that up rather than asking again. Where a separate sign-in is genuinely needed we use a proper browser-based flow rather than a username and password box inside a popup, which users are right to distrust.
Storage, and its limits
Extension storage is small and per-profile. Synced storage is smaller still and quota-limited, so it suits preferences and nothing else. Anything a user would be upset to lose goes to your API, not into the browser.
From Finished Build to Listed, Without Three Rejections
Review is not usually slow. It is usually repeated, because the same small omissions get flagged each time.
Before the build ends — the accounts exist
Developer accounts on the Chrome Web Store and Microsoft Edge Add-ons, registered in your company name rather than an individual’s, with identity verification completed. Doing this in the last week is how a launch slips, because verification is not instant and Chrome charges a small one-off registration fee that somebody has to approve.
Alongside the build — the listing and the justifications
Description, screenshots, icons, a privacy policy at a stable URL on your own domain, a data use declaration, and a written justification for every permission in the manifest. We prepare these as part of the build rather than scrambling for them at submission, because the justifications frequently change the code: writing one down is how you notice a permission you do not need.
Submission — and an honest expectation
Chrome review is often quick and occasionally is not, particularly where broad host permissions are involved. Edge follows its own queue. Firefox may include a human reading the source, so the build needs to be reproducible from the code you submit. We do not promise a date on somebody else’s review queue; we promise the submission will not be the reason for a delay.
Rejection — the four reasons it usually happens
A permission requested but not justified or not used. A privacy policy that does not match what the code does. Doing more than the single purpose the listing describes. Anything that looks like executing code fetched from elsewhere. All four are avoidable at build time, which is exactly why we treat the listing as part of the build.
Afterwards — releases that do not scare anyone
Updates are staged to a percentage of users rather than pushed to everyone at once, so a mistake affects a few people and gets pulled. New permissions are worth avoiding in an update wherever possible, because they can disable the extension until each user re-accepts them, which is a very effective way to lose an installed base.
Extensions Inside a Locked-Down British Company
A large share of UK extension work never goes near a public store. It is an internal tool for staff on managed Windows machines, and the deployment model is completely different from the consumer one. This is usually the easier project, provided it is designed for from the start.
How it reaches the machines
- Force-installed by policy. Chrome and Edge both let an administrator install an extension on every managed device through Group Policy or Intune. It appears without anybody visiting a store, and users cannot remove it. Firefox has an equivalent policy where it is part of the estate.
- Unlisted rather than public. An unlisted store listing is fully reviewed and installable by anyone with the link, but does not appear in search. This is usually the tidiest route for something you do not want the world to find.
- Self-hosted, rarely. Chrome permits a package hosted outside the store for managed machines, with an update feed you run yourself. It works, it is more fragile, and we recommend it only when a store listing is genuinely unacceptable.
What makes IT say yes
- Configuration delivered by policy, not by the user. Your server address, the site identifier, feature switches and whether sign-in is automatic, all set centrally through managed configuration so nobody types anything on first run.
- A short, honest permission list, with a written justification for each. This is the document that gets read in a security review, and a wildcard host permission is the thing most likely to stop the deployment.
- A data flow note. What leaves the browser, where it goes, what is retained and for how long. A UK enterprise buyer will ask about UK GDPR and will want a data processing agreement, and having this ready shortens the process by weeks.
- A pilot ring. A small group of real users on the actual standard build before the estate-wide push, because managed environments have proxies, application control and profile behaviour that a developer machine does not.
Where the extension talks to a system your IT team also owns, we work directly with them rather than through a project manager relaying questions. It is faster and it is how the deployment note ends up accurate.
The Maintenance Nobody Puts in the Original Budget
Extensions are among the smaller things we build and among the most reliably in need of attention afterwards. It is worth knowing why before you commission one.
Browsers ship every few weeks
Most releases change nothing that affects you. A handful each year deprecate something, tighten a policy or alter behaviour an extension depended on, and the notice period is not generous.
Target sites get redesigned
The pages worth building against are maintained by people who change them without telling you. A redesign breaks a content script silently, which is why we make ours report back when the page stops looking the way they expect.
Store policies move
Rules about permissions, data declarations and what counts as a single purpose are tightened periodically, and compliance is checked at your next submission rather than announced individually.
Visible failure beats silent failure
When something the extension expected is missing, it should say so to the user and report it to your service. An extension that quietly does nothing is worse than one that admits it is broken, because nobody reports it.
A small retainer is the right shape
A couple of days a quarter covers browser changes, the occasional selector repair and a resubmission. Less than most clients expect, and considerably less than reconstructing the context six months after the build finished.
You hold the accounts
Store listings, developer accounts and signing keys in your company name from the first submission. An extension you cannot publish an update to is an extension you do not really own.
Extension Questions Worth Asking First
When is a browser extension the wrong answer?
Whenever the work happens inside your own application rather than on a page that belongs to somebody else. If you control the page, build the feature into the page, where it is easier to build, test and support and where nobody has to install anything. Extensions also make poor mobile stories, because Chrome on Android does not support them and Safari on iOS supports only a limited form. And an extension is the wrong place to hold the important data: treat it as an interface to your service, not as the service.
Can our IT team push the extension to every laptop automatically?
Yes, and for internal tools that is usually how it should be distributed. Chrome and Edge both support force-installing an extension through Group Policy or Intune, so it appears on every managed machine without anyone visiting a store or clicking install, and users cannot remove it. Firefox has an equivalent enterprise policy. You can also push configuration alongside it, such as your own server address, so the extension arrives already pointed at the right place. We give your IT team the policy values and a short deployment note as part of the handover.
Can we keep the extension off the public store entirely?
You have a few options and they differ by browser. The tidiest is an unlisted store listing, which is fully reviewed and installable by anyone with the link but does not appear in search. Chrome and Edge also allow force-installed enterprise deployment for managed devices. Self-hosting the package outside the store is possible on Chrome for managed machines but is more fragile and needs you to run the update feed yourself, so we only recommend it when a store listing is genuinely not acceptable.
Do we need a Safari version as well?
Only if your users are on Macs in numbers that justify it, and you should know that it is a separate piece of work rather than a checkbox. Safari extensions are packaged inside a native macOS application, built with Xcode, submitted to the Mac App Store and tied to an Apple Developer account. Much of the extension code can be shared, but the packaging, review and release process is its own project with its own timeline. For most UK business tools, Chrome and Edge cover the great majority of users and Safari is a second-phase decision.
What happens to the extension when the site it works on gets redesigned?
It breaks, quietly, and you find out from a user rather than from a monitor. Any extension that reads or modifies a page it does not own depends on that page staying broadly the same, and the sites most worth building against are the ones that change most. We reduce the damage by writing resilient selectors, failing visibly rather than silently, and reporting back to your service when the page no longer looks the way the extension expects, so you know within hours rather than weeks. It is also the main reason these builds need a maintenance arrangement.
What personal data does an extension collect, and what must we tell people?
Whatever you choose to collect, which should be as little as possible, and you have to declare it. Both the Chrome Web Store and Microsoft Edge Add-ons require a privacy policy URL and a data use declaration, and a mismatch between what you declare and what the code does is a common reason for rejection. Under UK GDPR you still need a lawful basis for anything that identifies a person, and a corporate buyer will ask where the data goes and whether you will sign a data processing agreement. We keep the answer short by keeping collection minimal.
What does a browser extension cost to build and maintain?
A focused single-purpose extension for one browser family, talking to an API that already exists, is one of the smaller pieces of software we build, and generally lands in the low thousands of pounds excluding VAT. What moves the figure is the number of third-party sites it has to understand, whether it needs its own backend, whether Firefox and Safari are in scope, and how much of the work is reverse engineering pages with no documentation. Maintenance is the part to plan for, because browsers and target sites both keep moving.
What an Extension Usually Sits Next To
Web Applications
The product the extension is a window onto, and frequently the better place to build the feature outright.
Learn moreBackend & APIs
Where the rules and the records belong, so a change ships without waiting for a store review.
Learn moreMVP Development
An extension is sometimes the cheapest way to test whether anyone wants the thing at all.
Learn moreDescribe the Clicks You Want to Remove
Which page, which repeated action, and how many people do it each day. We will tell you whether an extension is the right answer, and what it costs in sterling excluding VAT if it is. Reply within two working days.