Browser extension development: use cases, permissions and publishing

A browser extension is a small program that runs right inside Chrome, Edge, Firefox or Safari: it adds a button, reads the data you need from a page, fills in forms or connects the site an employee has open with your CRM and services. A simple extension with one workflow usually takes one to two weeks to build, plus a few days for store review.

What an extension can do

An extension is useful when the work already happens in the browser but the site lacks the action you need. Instead of a separate app, an employee or customer presses a button on the very page they are on.

• Data capture. A product card, contact or listing is saved to your CRM or spreadsheet in one click, with no copy-pasting.
• On-page hints. The extension shows a status, price or customer history from your system next to the right field.
• Form filling. Repetitive fields in dashboards and admin panels are filled in from your data.
• AI agent connection. Selected text or the open page goes to an agent and the answer returns in a side panel — see “AI agent for business”.
• A customer product. A standalone extension as a product of its own or as a companion to your web service.

If the task is bigger than one action on a page, a web service or a Telegram bot may fit better. We discuss this when we review the task: sometimes an extension is the shortest path, sometimes an extra layer.

How a modern extension is built

Chrome, Edge and other Chromium browsers accept extensions in the Manifest V3 format; Firefox supports the same format with minor differences, and for Safari the extension is packaged into an app with Xcode. One codebase therefore usually covers all four browsers, with the differences handled by small build settings.

• A background service worker handles events and talks to your server.
• A content script reads and changes only what is needed on specific sites.
• A popup or side panel is the extension’s interface.
• An options page handles sign-in, mode and language.

Manifest V3 forbids remote code: all extension logic goes through store review, while data and rules come from your server.

Permissions and security

The key question for both users and store review is which permissions an extension asks for. The broader the access (for example, to all sites), the stricter the review and the more cautious people are at install time.

• Request access only to the sites where the extension works.
• Never store passwords or keys in the extension — sign-in goes through your server.
• State in the privacy policy which data is collected and why.
• Validate every incoming field on the server instead of trusting page data.

We apply the same rules to our own products: security is a requirement for every change, not a separate stage before delivery.

Publishing in extension stores

Extensions are published in the Chrome Web Store, Microsoft Edge Add-ons, Firefox Add-ons and the App Store (for Safari). Each store needs a description, screenshots, icons, a privacy policy and a justification for every permission requested. Review usually takes from a few hours to a few days, longer for broad permissions.

An internal company tool does not have to be published publicly: it can be installed from a private link or through the company’s browser management.

Timelines and cost

An extension with one workflow — a button, reading the page and sending data to your service — usually takes one to two weeks. Connecting several systems, account sign-in, a side panel with an AI agent and Safari support add time. We give an exact estimate after reviewing the task; what goes into it is explained in “Software development cost”.

It is best to start with one workflow for one browser and add the rest in later releases: value arrives sooner and decisions are tested on real users. More in “MVP development”.

Extension, web service or bot: which to choose

An extension is not the only way to add a missing action to everyday work. A web service or a messenger bot can solve similar tasks, and the choice depends on where the person is at the moment they need help.

Often the right answer is a combination: the web service stores data and rules, the extension adds a button on the right page, and the bot sends notifications. More on the web side is on the web app development page, and on bots in the guide Telegram bot for business.

Extension development stages

The work moves in short steps, and each one ends with something you can try with your own hands.

1. Task review. We pin down one main workflow: which sites the extension works on, what it reads, where it sends data and what the user sees. This is also where we decide which permissions are really needed.
2. Prototype. We build a working button or side panel on one site and in one browser to make sure the page data can be read reliably.
3. Server side. We set up account sign-in, data intake, field validation and writing to your CRM, spreadsheets or other systems.
4. Interface and copy. The popup, settings, clear error messages and interface languages.
5. Testing. We test on real pages, in different browser versions and on a slow connection, and separately check how the extension behaves when a site changes its layout.
6. Release. We prepare the description, screenshots, privacy policy and permission justifications, then submit to store review or distribute through a private link.

What to check when accepting each stage is covered in detail in the software project handover checklist.

Updates after release

An extension runs on other people's pages, so its life depends on more than your own code. The site it reads data from can change its layout, the browser can change its extension rules, and the store can change its requirements for descriptions and permissions.

• Page-reading rules, such as which fields to look for and where, are best kept on the server as data: when a site changes, part of the fix ships without a new store review.
• Extension errors should be collected in a server log — without personal data, but with the extension and browser versions and the page address.
• Every update goes through store review again, so larger changes are easier to bundle into planned releases, while urgent fixes ship separately.
• Browsers update automatically, so the extension should be checked on new versions in advance, not after users start complaining.

We plan support after launch from the start: a short check after browser updates and fixes from the error log cost less than an emergency repair.

Common mistakes

Most extension problems come not from the code but from decisions made at the start.

• Overly broad permissions just in case. Access to all sites makes store review harder and puts people off at installation.
• Keys and passwords inside the extension. Extension code can be opened and read, so everything secret stays on the server only.
• Logic tied to an accidental layout. If the extension looks for a button by an auto-generated class name, it breaks with the first site update.
• Four browsers and ten features at once. The first version ships later, and the value of the main workflow remains unproven.
• No privacy policy. Without a clear description of what data is collected and why, stores reject the extension.
• No update plan. An unsupported extension stops working quietly, and you find out from your users.

How we work

We build extensions as part of our custom software development service: we start with a task review, name the timeline and scope of the first version, and then deliver it in short stages. The code, extension store accounts and server side stay with the client.

The experience we draw on comes from our own products Wallet, Legal and the Content Factory: server side, account sign-in, AI features, publishing in app stores and support after launch. We apply the same rules to extensions — minimal permissions, keys on the server only, an error log and planned releases.

If the extension is part of a bigger product, such as a companion to a web service or an AI agent, we discuss everything together: that makes it easier to avoid duplicated logic and keep data in one place.