The browser is where your team works. Build for it.

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 extension advice online still describes the old model, and extensions built on those patterns either fail review or behave unpredictably.

The practical implications are concrete. Your background logic cannot assume it stays alive — state must be persisted to storage and restored, and long tasks must be 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, which shapes what is possible for content filtering and header manipulation.

We build MV3-native rather than porting MV2 patterns, and we design around these constraints from the architecture stage. 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.

The highest-value extensions 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. A pharmaceutical distributor's staff were checking product codes against an internal database in a separate tab; the extension shows the match inline on the supplier's page.

Other patterns that recur: pre-filling long forms in government or bank portals from your own records, capturing leads from LinkedIn or a marketplace into your CRM, overlaying your credit and stock position on a customer's 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. 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. We calculate this explicitly before quoting so the decision is arithmetic.

For internal tools you rarely want the Chrome Web Store's public listing. We deploy through enterprise policy so the extension installs automatically for your users, cannot be removed by them, and updates from a source you control. It works with Google Workspace, Microsoft Intune and Active Directory group policy.

Governance matters as much as capability. An extension has significant access to whatever pages it runs on, so we scope host permissions as narrowly as the job allows, keep credentials out of the extension entirely by proxying through your backend, log what the extension does for audit purposes, and version it so a rollback is immediate. We also document exactly what data the extension touches, which is the question your IT security reviewer will ask first.

Publishing is straightforward if you understand the review process and painful if you do not. The most common rejection reasons are a permission requested without a clear justification, a privacy policy that does not match declared data usage, a description that overstates functionality, and remotely hosted code.

We handle the whole submission: listing copy written for store search, screenshots and promotional assets at every required size, a privacy policy that accurately describes data handling, permission justifications written for a reviewer rather than a developer, and responses to any review queries. Our own seven published extensions mean we run this process regularly rather than once a year.

Post-publication we handle the ongoing part that people forget: responding to user reviews, monitoring for breakage when Chrome updates, and adapting to policy changes that Google issues with limited notice.

Most business extensions only need Chrome and Edge, which share the same extension model and require essentially no additional work — one build, two store listings. Firefox uses a compatible but not identical API surface and generally needs a modest compatibility layer. Safari requires wrapping in a native application shell and going through Apple's review, which is a meaningfully larger undertaking.

We advise on this early based on your actual user base rather than defaulting to all four. For an internal tool in an organisation standardised on Chrome or Edge, building for Safari is pure cost.

An extension is a piece of software with access to page content, and users are right to be cautious about them. We treat that seriously. Data stays local unless there is a stated reason for it to leave. Network calls go only to endpoints you control. Content scripts run in the isolated world and never expose privileged functions to the page. Permissions are requested at the narrowest scope, and optional permissions are requested at the point of use rather than at install, which materially improves install conversion for public extensions.

For our own published extensions we hold to the same standard we recommend: process locally where possible, collect nothing that is not needed, and state plainly in the listing what happens to data. It is both correct and, in a category where users are suspicious, a competitive advantage.