Custom browser extension
It removes repeating actions right in the browser: creating deals, filling in fields, sending a template.
- Buildfrom $1,900
- Timeline2–4 weeks
- Supportfrom $140/mo
Who this suits: Work that lives entirely inside somebody else’s interface, a CRM or a supplier portal, where the API is missing or locked behind a plan nobody buys.
What is in the first version
- in-page buttons
- field autofill
- message templates
- handoff to CRM
The figures above are the package this sits on: Browser extension. Anything past its edges the calculator adds before the work starts, not after.
How the path goes
- 01
The extension recognises the page
It wakes only where it has something to do and puts its button where the cursor already is.
- 02
The data comes off the tab
Whatever the person can see, the extension reads, lays into the fields of another form or sends to your system.
- 03
The action is confirmed, not assumed
What goes and where is on screen first, since a deal created silently in the wrong place costs more.
What decides whether this works or annoys people
Permissions decide whether it gets published
Access to all sites means a long store review, so the address list is narrowed before the first line of code.
Somebody else’s interface changes without warning
A redesign breaks the binding to a field silently, so the extension checks it found what it expected and reports a change.
Old versions stay live
The store review sits between publishing and everyone having it, so the extension and your server agree on a version.
What to measure once it is live
- actions done from the extension
- clicks per operation
- page binding failures
- team on the current version
Why this comes out faster
The shape of this one is known: the states, the edge cases and the things that usually go wrong have been decided before. Nothing here is a template, and the saving is not in your half of the work. It goes into your process, your content and the systems this has to talk to, which is the part nobody can have solved in advance.
A likely stack for this
Picked against the task when we scope it, not decided in advance. This is the shelf it usually comes off.
- ExtensionTypeScriptReactChrome Manifest V3
- Backend and dataNode.jsPostgreSQLRedisS3
- Tests and operationsPlaywrightDockerGrafana
Price it yourself, right here
Five steps, and you can see the number without leaving a contact. The estimate accounts for the kind of work, what you already have and what it will need inside.
These bills do not come from us
- a Chrome Web Store developer account
- hosting, if there is a server side
- the domain for the privacy policy page
- AI model calls, if it rewrites text
Asked before the first call
- Will the service notice we are using an extension?
- It works in the browser as the person already signed in, doing what they do by hand. The limit is that service’s terms, and we say so before the estimate rather than after a block.
- What if the service does have an API?
- Then take the API, and we say so. An extension earns its place where there is no API, where it costs more than the job, or where it does not return what the screen shows.
- Does it have to go into the store?
- No. For an internal team it is distributed privately and updates depend only on you; publication matters when your clients install it, and then the review is planned in.