Does your app need to be an app?
Some of the ideas that reach us are not mobile apps. Saying so on day one is cheaper than saying it six months in.
We tell some of the people who approach us not to build a mobile app. It is a sentence that costs us work, but the alternative is worse: discussing the invoice for an app nobody downloaded, six months later.
The decision comes down to one question: how often will someone open it?
The three things an app actually gives you
A mobile app only beats a website in three places:
Access to the hardware. Camera, GPS, bluetooth, biometrics, background location. Browsers do some of this, but partially and with prompts.
Working without a connection. In a warehouse, in the field, in a basement. If data has to live on the device and sync later, you need an app.
Occupying the home screen. This is not a technical feature, it is a habit. As long as the icon sits there, people remember you.
If none of these apply, you are probably looking for a website.
The install barrier is underestimated
There is a canyon between opening a web page and installing an app. The user has to go to the store, search, wait for a download, approve permissions, create an account. You lose people at every step.
That barrier is only repaid by repeat use. Nobody accepts it for something they will open once a month.
A rough split:
| What it does | Where it belongs |
|---|---|
| A catalogue or price list checked monthly | Web |
| A one-off application, form or booking | Web |
| Daily tracking, ordering, messaging | App |
| Fieldwork, offline, camera | App |
The "let's do both" trap
We hear it often. It sounds thorough, but in practice it means two products: two designs, two codebases, two test cycles, two maintenance loads. Split the budget and you usually end up with two half-finished things.
Choosing one channel and doing it properly beats doing two halfway, every time. If the second one turns out to be genuinely necessary, you will decide based on the first one's data instead of a guess.
The middle path: web first, app later
If you are not sure the idea will land, the order should be:
- Ship a mobile-friendly web version
- Measure how many people use it, and how often
- Talk about an app when the same people come back more than once a week
This is cheaper, and by the time you build the app you know what to build. The gap between a first version built on assumptions and one built on measurements can be close to the cost of the whole project.
What we actually do
In the first conversation we listen to the idea and answer this question together. If the answer is "a website is enough", we say so. That conversation is free and carries no obligation — because building the wrong product wastes both our time.