Web first or app first?

It is asked as a channel question — do we need an app? — and answered as a status question, because a competitor has one. Neither framing produces a good decision. The question that actually decides it is about frequency: how often does one customer need you?

The split is close to a rule. The web wins acquisition, because it is where a stranger arrives from a search, a link or an advertisement, at no cost and with no commitment. An app wins repetition, because it is the only surface that a person has agreed to keep. If a customer touches your business less than about once a month, an app is a bookmark that occupies ninety megabytes and will be deleted during the next storage panic. If they touch it weekly, the app is where the relationship lives and the website is the shop window.

The test we use is whether the product needs any of four permissions a browser does not have: to know who you are without being told again, to remember where you left off, to speak first, and to work when the network does not. An app that uses none of the four had no reason to exist. An app that uses all four — saved details, one-tap repeat, a notification worth allowing, an itinerary that opens in aeroplane mode — is a habit, and habits are the only defensible thing in a consumer business.

For most companies the sequence that works is web first, but with one condition that costs almost nothing at the start and everything later: the API is designed as the product's API rather than the website's. That means the business logic lives behind an interface rather than inside a page, the data model is not shaped by one layout, and authentication is issued as tokens a client can hold rather than a session a browser owns. Do that, and the app becomes a second consumer of a system that already works. Skip it, and the app project begins with three months of rewriting the back end, which is the invisible reason so many app quotes are surprising.

The middle path deserves a fairer hearing than it usually gets. A progressive web app — a website that can be installed to the home screen, work offline and receive push notifications on both iOS and Android — now covers a genuine majority of what most branded apps actually do. It ships without store review, updates instantly, and costs one codebase rather than two. What it still cannot do is the platform-deep work: background location, tight hardware access, widgets, the share sheet, biometrics beyond the web standard, and the shelf position that comes with being in a store at all. For a loyalty scheme or a content product, that list is not missed. For a delivery, banking or travel product, it is the product.

The consequence people underestimate is organisational rather than technical. Two surfaces means two release trains, two sets of analytics, two support scripts and two places for a bug to be reported and only fixed in one. A company that cannot keep one website current will not keep an app current, and a neglected app does more damage to a brand than no app, because the customer already agreed to give it space and it repaid them with a crash.

So: web first, unless the product genuinely needs the four permissions, and unless somebody inside the business is going to own the app for years rather than for a launch. The version of this question worth asking is not which one do we build. It is which of these are we prepared to still be maintaining in 2029.