Browser Extension

People spend most of their working day inside a browser, and for a long time there were only two ways to change what that browser did. Build a browser, or install a separate program that ran outside it. Both are steep prices to pay for adding one button.

So users moved things by hand, tab by tab. That was Sofia's day in Pagedeck's early sales work. Reading a prospect's website and wanting to write something down meant switching tabs, finding that account's document, pasting, and then remembering what she'd been reading in order to go back. Four steps per note, roughly twenty times a day. What actually happens at that point is that people stop writing things down.

Browser extensions exist because the companies building browsers opened this up. They defined a seat where somebody else's code could sit, and wrote rules for what that code may and may not do from there. A single small feature no longer required building an entire browser around it.

It lets a user finish a task without leaving the screen they're already looking at. This is where those four steps collapse into one click.

What extensions actually do falls into four groups.

1. Adding something on top of someone else's page. A panel down the right side of a prospect's website, with a note field in it. No relationship with that company is required, and they don't have to know the panel exists.
2. Filtering or changing what's displayed. Hiding ads, or overwriting foreign-language sentences with a translation in place, so the page the user reads is not the page the site sent.
3. Capturing what's on screen. Grabbing the page address, the title, and the selected sentence in one action and sending them into your own service.
4. Changing the browser itself. Replacing the page shown on a new tab, or adding keyboard shortcuts.

What makes this hard to substitute is the seat, not the feature. An extension is the only product that can get inside someone else's page. A web app can only draw within its own address, a mobile app is on a different device entirely, and a desktop app can reach files outside the browser but not into the page the browser has already drawn.

Two advantages come along with the form. The first is distribution: each browser runs an extension store, so people find you by searching and install in one step, with no account setup in between. The second is the session. If the user is already signed in to your service in that browser, the extension inherits that state. Very few product forms get to skip asking for a login, and skipping it removes the step where most first-time users drop out.

Three other approaches address the same problem — reaching a user with your functionality while they work inside a different screen.

1. Let them use another tab. Leave the web app as it is and suggest arranging two windows side by side. Nothing to build, which is the real advantage, and the moving of information is still done by a person.
2. Connect server to server. If the other service exposes a way to be called from outside, the way an API product does, data moves without passing through any screen. Cleanest by far, since no human is in the loop, but it only exists if the other side opened that door.
3. Go inside their product. Large services usually become a platform and offer a slot for other people's features. An app in that slot runs inside their interface, but what it is allowed to do is decided by them.

Extensions usually get chosen when options 2 and 3 are closed. The other company hasn't opened a door or a slot, the user works in that screen anyway, and the browser is the remaining way in. That also means the form is often a temporary answer: teams build the extension now and move to a server connection later, once the other company is willing to talk.

Three costs come with that. The browser vendor can change the rules and break your extension the day it lands — every revision to the extension format has forced a large share of existing extensions to be rebuilt. Mobile browsers mostly don't support extensions, so the form reaches desktop users only. And because it asks for permission to read and modify other people's pages, store review is strict and some users hesitate at the permission screen right before installing.

"I think this has to be an extension. They never opened an integration endpoint."

There's no way to connect server to server, so the connection gets made at the screen instead.

"Installs are at 40,000 but weekly actives are 6,000."

A large share of people installed it once and never came back.

"The format changed, so we need to ship an updated extension by next month."

The browser vendor revised its rules and unplanned work just appeared.

Pagedeck built one because sales asked for it. Sofia wanted to record what she saw on a prospect's site without leaving it, and Mia narrowed the request to two features: save this page into a document, and attach the selected sentence as a quote.

The lesson came afterward, on the maintenance side. Theo shipped the first version in two weeks, and from then on every quarter carried work to keep up with browser format changes. The company had acquired a product whose workload didn't shrink even when its feature list didn't grow. Pagedeck decided not to add anything more to the extension, and it still ships with only those two features.

The most common assumption is that something small is quick to build. One panel, one or two features — it looks like a week of work. But the effort scales with the number of things you have to keep up with, not with the size of the surface. Formats differ slightly across browsers, so two or three variants need to stay in sync; every release waits on store review; and when someone else's page structure changes, your button appears in the wrong place. Teams that treat it as easy find that a two-week project became a recurring quarterly one.

The second mistake is reading installs as users. The install count is the number the store shows you, so it's the one that lands first. In practice the install-and-forget rate is far higher here than in other product forms. Forty thousand installs against six thousand weekly users is not even a bad result. Chasing the install number pushes a team toward store visibility work, when the question worth tracking is whether someone who installed it clicked it even once during their first week.