The web became the operating system
You noticed when you got a new laptop and were fully operational in twenty minutes, because almost nothing needed installing. That is the moment the shift was already finished — not announced, just complete.
The browser stopped being the place you look things up and became the place the work is. What follows is what that implies for anything built now, and where the counter-argument is stronger than people building for the web usually admit.
The shift that happened without a launch
For most knowledge workers the list of things that migrated from installed applications to web interfaces is long and still lengthening: documents, spreadsheets, project tracking, communication, data analysis, financial modelling. The browser is not a viewer for remote content. It is the surface on which the work is done.
It happened gradually and then very quickly, and by the time anyone wrote about it, it had already happened. You noticed when your team's shared idea of "the file" stopped meaning something on a drive and started meaning something at a URL. You noticed when receiving a native application instead of a link began to feel like a small imposition rather than the normal way of things.
None of this happened because anyone planned it. It happened because it solved specific problems: access from anywhere, sharing without attachment, updates without installation, collaboration without version drift. Those are unglamorous benefits and they were decisive.
The counter-argument, made properly
This is where most web-first arguments get lazy, so here is the strong version.
Native applications are faster, and not marginally. They work offline, which matters more than web-first people admit — the flight, the train, the client site with unreliable connectivity, the whole category of work that happens where there is no network. They reach hardware in ways a browser cannot. They keep working when the vendor's servers do not, and they keep working the day after the vendor changes something you depended on. And they do not silently redesign themselves overnight.
For whole categories of work — professional creative tooling, software development, anything involving large local files — the native application is still simply the right answer, and it is going to stay the right answer. Pretending otherwise is a marketing position, not a technical one.
There is a sharper version of the objection too, and it is the one worth sitting with: the web made your tools revocable. A local application you have installed cannot be taken away, repriced, or feature-flagged out from under you. The shift to the browser handed a large amount of control from the people using software to the people running it, and the convenience that bought was real but it was not free.
We do not have a rebuttal to that. It is true. What we have is a position on which trade to make and an obligation to be honest that it is a trade.
Why we chose the web anyway
Building askFinz web-first was a conclusion about where the work is, not a shortcut.
A tool that lives in the browser lives where your work already lives. The research you are doing, the document you are writing, the numbers you are checking — all of them are already there. An AI surface inside the same environment as the work is categorically different from one that requires leaving that environment to consult it, because the distance between "checking the assistant" and "doing the work" goes to roughly zero, and that distance is what determines whether a tool gets used in the middle of a task or only at the start of one.
The second reason is collaboration. Shared context. Live co-presence on the same material. A result that is a link rather than a file you send and then version. These are not secondary conveniences of a web interface — they are the reason the migration happened in the first place, and they are extremely hard to retrofit onto an application built for one machine.
For the specific work askFinz is built for — research, synthesis, writing, analysis, reasoning about numbers — the constraints that dominate are access, collaboration and adjacency to everything else. The web handles those better than any installed application. For work dominated by latency, offline capability or local file size, it does not, and we would say so.
What we rejected
A native app first, web later. The argument was that the demanding users are on desktops, that performance is a differentiator, and that a native surface signals seriousness. We rejected it because it optimises for the impression of a serious tool at the cost of being present where the work happens. A tool you have to switch to is a tool you consult; a tool that is already there is a tool you use. That difference decides adoption more than performance does, for this category of work.
A browser extension as the primary surface. Superficially the best of both: it sits directly on top of whatever you are already doing, with no context switch at all. We looked hard at this and did not take it as the primary form, for a reason that only becomes obvious after you sketch it. An overlay is excellent for acting on the page you are on and structurally poor for work with its own shape — a research thread that spans days, a document with state, anything that needs to be somewhere rather than on top of something. Building the main product as an overlay would have meant every piece of durable work living in a panel that disappears when you navigate. That is a good assistant and a bad workshop.
Chasing offline. We considered making offline capability a headline commitment and decided against promising it. Partial offline support is worse than none, because it teaches people to rely on something that will fail at the moment they most needed it — which is, by definition, the moment they were offline. We would rather be clear about the constraint than half-satisfy it.
What we would do differently
We would have designed for the bad network rather than the missing one.
The offline conversation is a binary that absorbed all the attention: connected or not, and if not, what happens. The condition that actually describes most professional work is neither — it is the degraded network. The hotel connection, the conference wifi, the train. That state is far more common than genuine offline and it is where a web-first tool feels worst, because everything is technically working and nothing is usable. We reasoned about the dramatic case and under-designed for the ordinary one, which is the wrong way round for a product whose entire argument is that it should be where the work already is.
The migration is not finished; more surfaces move to the browser each year and more capability that once needed native code is now available in it. What is clear is that the tools built for this environment will not be desktop applications ported onto a page. They will be built around what the web actually enables — persistent sessions, shared context, live collaboration, results that travel as links.
askFinz is built on that assumption. Not because the web is fashionable, but because that is where the work already is.