The honest answer is usually a website first, and we say so often enough that it is worth writing down why, along with the cases where it is genuinely wrong.
The question is rarely about technology. It is about whether you have earned a place on somebody's home screen, because that is what an app is asking for.
The thing people underestimate: getting it installed
A website is a link. You put it in a bio, a message, an invoice, a poster, an advert, and the person is on it in a second. An app requires them to go to a store, search, choose the right one among similarly named results, wait for a download on their data, open it, and usually create an account before they see anything.
Every one of those steps loses people, and the losses compound. For a business whose customers do not yet know them, this is usually the whole argument. You cannot acquire customers through a channel they have to commit to before they can look.
What an app genuinely gives you
There are real capabilities here, and if you need them, nothing else will do.
- Notifications people actually receive. Web push exists and works on Android, but on iPhones it requires the site to be added to the home screen first, which most people never do. If your model depends on reaching someone who is not currently thinking about you, that is an app argument.
- Working offline, properly. A website can cache a great deal, but an app that must function with no signal for an hour (a field survey, a delivery route, a stock count) is on firmer ground.
- Deep access to the device. Continuous background location, Bluetooth peripherals, sustained camera work, biometric storage.
- Being on the home screen. If someone opens you several times a week, an icon is worth real money. If they open you twice a year, it is an icon they will delete.
What an app costs that nobody mentions in the first meeting
- Two platforms. Even sharing a codebase, iOS and Android differ in behaviour, review and hardware. Testing is not halved.
- Store review. Every release is inspected by somebody else, on their schedule. A critical bug on a website is fixed in minutes; in an app it is fixed when it is approved.
- Developer accounts, annually, and Apple's requires a Mac in the build chain.
- Old versions living forever. Some users will not update, so your server has to keep speaking to the app you shipped two years ago.
- Store presence as a discipline: screenshots, descriptions, ratings, replies to reviews.
The build is the smaller half. Everything above is permanent.
The middle option most people have not considered
A website can be installable. It can sit on the home screen with its own icon, open without browser chrome, work offline for what it has already seen, and on Android send push notifications. It is one codebase, one deployment, no store review, and it is a link, so it can still be shared.
It is not a complete substitute. iOS restricts it in ways that matter, notably around notifications and background work, and the install prompt is far less obvious. But for a large class of products (a portal, a dashboard, a booking tool, an internal system), it delivers most of what people wanted an app for, at a fraction of the cost and none of the release friction.
Four questions that usually settle it
- How often does one person use this? Several times a week points to an app. Occasionally points to the web.
- Do you need to reach them when they are not thinking about you? If yes, and iPhone users matter, that is the strongest app argument there is.
- Does it have to work with no signal? Genuinely, not theoretically.
- How will people find it in the first year? If the answer is advertising, search or word of mouth, they need to be able to look before they commit.
If none of those points to an app, an app will probably be built, launched, and then quietly carried as a cost.
When we say build the app
When the product is used daily and notifications are the product: logistics, dispatch, field teams, anything where somebody is told to do something and must act. When the hardware is the point. When offline is a requirement rather than a nice-to-have. And when there is already a web product with usage data proving people come back.
What we push back on is an app commissioned to look serious. That is an expensive way to look serious, and the version of it that gets built without a real usage case tends to launch to an empty store page.
Tell us what has to happen and how often, and we will tell you which of the three this is, including when the answer is the cheapest one.
