Web App

For a long time, using software meant installing it first. You downloaded an installer, ran it, clicked through warnings, and repeated the sequence every time a new feature came out. For the company shipping it, that arrangement created three standing costs: a separate build per operating system, a fix that was not a fix until each user chose to download it, and roughly ten versions of the product alive in the world at any moment.

Support conversations all had the same shape as a result. A customer wrote in to say saving was broken, and the first question back was which version they were running. The bug had been fixed in 2.3, the customer was on 1.9, and when the rep suggested updating, the answer was that their IT department would not approve the new installer this quarter.

A different path opened once browsers could draw interfaces and run real computation rather than only display documents. The program stays on a server instead of being copied onto the user's machine, and the browser is the window that fetches and renders it. Installation disappears, and pushing corrected code to the server once changes the version everybody runs at the same moment.

A web app removes the installation step sitting between a person and the product, along with the version drift that step used to cause.

1. The path to a first try gets shorter. Send one link and the other person can open the product where they are. Nobody drops out during the download, the warning, and the restart.
2. There is only one version in existence. Ship a fix on Friday and every customer is on the corrected screen by Monday morning. With installed software the same fix reaches customers weeks apart, if at all.
3. You do not build separately per operating system. One build runs the same way on Windows, macOS and Linux, so the team maintains one codebase rather than three.
4. Sharing stays inside the product. Send the address of a document and the recipient sees the same screen you do, without being asked to install anything first.

Points 2 and 4 are why Pagedeck is built this way. It is a product for writing documents together, so whoever gets a link must be able to open it immediately, and on the day a bug is fixed every team must be looking at the same version.

Teams reach for a different form factor mostly because of three things a web app does badly: it stops working when the connection drops, it is awkward on a small screen, and it has limited reach into hardware features such as the camera or push notifications.

1. A mobile app is installed on a phone. It can send notifications, and the icon left on the home screen makes reopening far more likely. The trade is that every release goes through app store review and the store takes a share of every payment.
2. A desktop app is installed on a computer. It gets the full performance of the machine and direct access to local files, which is why video editing and code editors still live here.
3. A browser extension attaches to the browser and runs on top of somebody else's website. What makes it unusual is that it appears inside the screen the user is already working in rather than asking them to come to yours.
4. API products and SDKs have no interface at all. The first is a channel another program sends requests to and reads results from; the second is a software development kit (SDK), a bundle of code installed inside someone else's application and running alongside it. When the user is another system rather than a person, this is the shape.

There is also a middle form covering part of the gap. A progressive web app (PWA) is built with web technology but packaged so it can be installed on a home screen and receive notifications — the first option to examine when one codebase needs to serve both situations.

Platforms and marketplaces sit in the same family but are not alternatives to a web app. The first describes whether other companies' services run on top of yours; the second whether you connect sellers to buyers. The same is true of SaaS, which describes selling software as a subscription with nothing to install. All three can be true at once: a marketplace sold to companies by subscription and delivered as a web app is an ordinary sentence.

"Let's ship this as a web app first and look at a mobile app next quarter."

Take the version that spreads by link with nothing to install, and see the response before committing further.

"It's a web app, so the deploy is live immediately. We don't need to send customers an update notice."

Using the absence of version drift as an argument for pulling a date forward.

"This table breaks in a phone browser. Being a web app doesn't mean it works everywhere."

Running in a browser and being usable on a small screen are two separate claims.

Pagedeck started as a single web app and that is still its center. Noa maintains a separate layout for narrow screens, and Theo checks that Safari and Chrome behave the same way before anything ships. Mia only decides whether a feature goes out this week or next; which customer is on which build never comes up.

The friction shows up on the sales side. Some of the companies Sofia talks to cannot keep documents on an outside server and ask for something installed inside their own network. Pagedeck does not revisit the form factor over those requests; a dedicated installed build gets handled as a separate contract.

The most common error is treating a web app and a website as the same thing. Both are addresses you open in a browser, so they look alike from outside. The difference is what the user does there. A website is somewhere you read what has been placed for you. A web app is somewhere you create, edit and save things, and what you did persists. That brings accounts, permissions, and handling for a save that fails halfway, so two projects with the same number of screens can differ severalfold in build effort. Confuse the two and you promise a document editor on the schedule for a company homepage.

The second error is assuming that running in a browser means running well everywhere. Browsers are on every device, so the conclusion is easy. But browsers render differently by vendor and version, and once the screen narrows, tables and multi-column layouts fall apart first. Skipping the installer does not remove testing work; it turns it into deciding which browsers and versions you support and then checking that list. Teams that never write the list down hear from a customer that one screen is broken only in Safari.