Browser extensions occupy a strange position: they are the highest-leverage software most companies never consider building. A staff member copying twenty fields from a supplier portal into your ERP forty times a day is losing roughly two hours daily to something an extension reduces to one click.
And unlike a system integration, it requires no cooperation from the supplier and no change to either application. That combination — high return, low dependency — is rare.
Why this is under-considered
Partly because extensions are associated with consumer utilities rather than business tooling. Partly because the workflows they would fix are invisible to management — nobody reports "I spent two hours retyping today" because it is simply what the job involves.
And partly because IT departments are, reasonably, cautious about extensions after a decade of acquired-and-monetised consumer extensions turning malicious. That caution is correct for extensions from unknown publishers and irrelevant for one you commissioned, control and deploy yourself.
The way to find candidates is to watch. Sit with a team for an afternoon and count the times someone reads a value on one screen and types it into another.
What Manifest V3 changed
Manifest V3 replaced persistent background pages with ephemeral service workers, restricted remotely hosted code, and changed how network requests can be modified. A great deal of advice online still describes the old model, and extensions built on those patterns either fail review or behave unpredictably.
The practical implications are concrete. Background logic cannot assume it stays alive — state must be persisted to storage and restored, and long tasks structured as resumable steps. Anything that must survive a service-worker restart needs an alarm rather than a timer. Request modification uses declarative rules with defined limits.
Build MV3-native rather than porting MV2 patterns. It is the difference between an extension that works on the developer's machine and one that works on a user's machine after their laptop has been asleep for four hours.
Where extensions genuinely pay
The highest-value ones we build are unglamorous. A logistics client's team was reading consignment details from four carrier portals and typing them into their own system; the extension reads the page and posts structured data with one click, saving about eleven hours a week.
Other recurring patterns: pre-filling long forms in government or bank portals from your own records; capturing leads from a marketplace or professional network into your CRM; overlaying your credit and stock position on a customer name inside a webmail thread; and validating data as it is entered into a third-party system so errors are caught before submission rather than after.
The economics are consistently favourable and easy to compute. If an extension saves ten people twenty minutes a day, that is roughly 830 hours a year — which at any reasonable cost of labour dwarfs a three-week build.
| Use case | Manual today | With extension | Annual saving |
|---|---|---|---|
| Carrier portal to internal system | 4 min per consignment | 10 seconds | ~570 hours |
| Government portal form filling | 12 min per filing | 90 seconds | ~210 hours |
| Lead capture to CRM | 3 min per lead | One click | ~180 hours |
| Price and stock lookup while quoting | 2 min per query | Inline, instant | ~340 hours |
| Validation before submission | Errors found later | Blocked at entry | Error cost avoided |
Enterprise deployment and governance
For internal tools you rarely want a public Chrome Web Store listing. Deploy through enterprise policy so the extension installs automatically for your users, cannot be removed by them, and updates from a source you control. This works with Google Workspace, Microsoft Intune and Active Directory group policy.
Governance matters as much as capability, because an extension has significant access to whatever pages it runs on. Scope host permissions as narrowly as the job allows. Keep credentials out of the extension entirely by proxying authentication through your own backend. Log what the extension does where compliance requires it. Version it so a rollback is immediate.
And document exactly what data the extension touches — that is the first question your IT security reviewer will ask, and having a written answer ready shortens the approval by weeks.
In practice
Security architecture that survives review
The extension should never hold long-lived credentials. It authenticates the user against your own backend, which issues a short-lived scoped token. If a device is compromised, the exposure is bounded and revocable centrally.
Content scripts run in the isolated world and must never expose privileged functions to the page — a page you do not control could otherwise call them. Network calls go only to endpoints you control. Optional permissions are requested at the point of use rather than at install, which for public extensions also materially improves install conversion.
Because you commission, control and deploy the extension yourself, the supply-chain risk that has caused problems with acquired public extensions simply does not apply. That is worth stating explicitly in the security review.
The maintenance reality
Extensions break when target sites change their markup. This is the main ongoing cost of the category and it should be in the plan rather than a surprise.
Reduce the exposure by anchoring to the most stable selectors available, adding graceful failure rather than silent wrong behaviour, and building health monitoring that alerts when extraction success drops. In our experience a given portal needs attention two or three times a year.
Budget for it explicitly — a maintenance agreement with a repair response time is the difference between a tool your team relies on and one that quietly stops working and gets abandoned.
Key takeaways
- Extensions are high-return and low-dependency — they need no cooperation from the target system.
- Build MV3-native; ported MV2 patterns behave unpredictably after a service worker sleeps.
- Compute the case in hours: ten people, twenty minutes a day is roughly 830 hours a year.
- Deploy internally via enterprise policy; never put credentials in the extension itself.
- Budget for maintenance — target sites change two or three times a year.
Frequently asked
Usually yes, if your staff can legitimately see that data with their own login. The extension reads the rendered page in the user's own session — it is not bypassing authentication. What we always check first is the target site's terms of use, because technical feasibility and permission are different questions.
Enterprise policy. Through Google Workspace, Intune or Active Directory you can force-install from a private source, prevent removal and control updates centrally. Your staff simply find it there next time they open the browser. We provide and test the policy configuration with your IT team.
With the right architecture, yes. The extension holds no credentials; it authenticates the user against your backend which issues a short-lived scoped token. Host permissions are limited to specific domains, actions can be audit-logged, and because you control the code and deployment there is no third-party supply-chain risk.
Yes, most often for MV2 extensions needing MV3 migration or abandoned internal tools whose developer has left. We start with an assessment of the code and permissions, then either repair and modernise or rebuild — whichever is genuinely cheaper, which we tell you after looking rather than before.