An app is a bigger project for us, so read the part where we tell you not to build one. The three cases where it genuinely wins, the costs nobody counts, and the retention arithmetic that settles it.
“We need an app” arrives as a conclusion rather than a question, usually after a competitor launched one. It is sometimes right. More often it is a costly way to postpone fixing the thing people actually use.
Worth saying before anything else: an app is a bigger, longer, more profitable project for a studio than a website. Read the section where we argue against one with that in mind.
Repeated use. Something people open several times a week — tracking, logging, ordering the same thing again, a tool inside their working day. Frequency is what pays back the install, and nothing else does.
Device capability. Sustained background location, deep camera work, Bluetooth hardware, tight integration with the phone's own features. If the product is impossible without them, the decision is already made.
Offline work. Field teams, warehouses, planes, basements. Real offline — collecting data with no signal and syncing later — remains an app's territory.
Notice what is not on the list: prestige, a competitor's launch, or the belief that customers want an icon on their screen. They almost never do; they want the thing to work when they arrive from a link.
When we dig into the request, the underlying wish is almost never the store listing. It is: I want it to be fast. I want customers to stay logged in. I want to reach them again. I want it to feel like ours rather than a page.
Every one of those is achievable on the web, and three of the four are cheaper there. Worth separating the wish from the delivery mechanism before committing to the most expensive version of it — the answer occasionally stays “an app”, and it is a much better-aimed app for having asked.
The build is the visible part. Around it sit expenses that only appear after launch.
Push is the argument that closes most app decisions, and it deserves more scepticism than it gets. Only a share of users grant permission; a further share revoke it after the third message that was not about them; and the ones who leave permission on have learned to ignore the badge.
Push works when the message is genuinely about that person right now — your delivery is arriving, your shift changed, the price you were watching moved. Push used as a broadcast channel performs like a weaker email list that you cannot segment as well and that people uninstall to escape.
Also worth knowing before this argument decides anything: installed web apps can send notifications on both major mobile platforms now, including on iPhone. The gap that existed a few years ago has narrowed considerably.
Here is the part that settles most cases. Somebody clicks your advertisement. On the web they land on a page and can buy in the same minute. With an app, they must visit a store, agree to a download, wait, open, sign up — and each of those steps loses a share of the people you already paid for.
For anything acquisition-driven — a store, a service, a new product looking for its first customers — that funnel is the entire argument. Build the app for people who already love you, not to meet them.
How often would one person use this? Weekly or more, an app can pay for itself. Monthly, it will sit on a home screen unopened.
Does it need something a browser cannot reach? Sustained background location, deep hardware access, genuine offline. If not, the strongest technical argument is gone.
Where will the users come from? If the answer is advertising, the store install stands between the click and the money. If the answer is customers you already have and speak to, the wall is much lower.
Put your own numbers into a short calculation: the build, plus yearly maintenance for both platforms, plus the store overhead, divided by the extra margin per customer that the app is supposed to produce. That gives the number of loyal, frequent customers who must adopt it before it breaks even.
Then ask honestly how many customers you have with that frequency. Most businesses discover the number is a few hundred, that those few hundred are already well served, and that the same budget spent on the checkout, the speed and the content would reach everybody else. Our three-year platform comparison uses the same method for the same reason: three years of ownership decides these things, not the build price.
The app that succeeds is usually narrower than the one first described. One job, done better than the website can do it, for the people who already use you weekly. No settings screen nobody opens, no duplicate of the marketing site inside a wrapper, no feature that exists because the competitor has it.
Ship that, watch what those people actually do, and grow it from evidence. The alternative — a full mirror of the business in app form — is the version that costs a year, launches to two hundred installs and quietly stops being updated.
There is a version people skip. Make the website fast, installable and usable with one thumb; let people add it to their home screen; use notifications where they are genuinely warranted. You get most of the benefit with one codebase, no store queue, and the ability to fix something in ten minutes.
When that stops being enough — when frequency is real, when the hardware matters, when offline is a requirement — build the app deliberately, for the audience that has already proved it wants one. That app tends to be smaller, better aimed and cheaper than the one that would have been built out of ambition at the start.