A mobile app: when you really need one and when a website will do
An app in a store costs more than people expect — and often solves what a site that works properly on a phone already handles. How to tell before investing.
A mobile app is not a website in a smaller window. It is a second product with its own release process, its own bugs and its own maintenance forever. Which is why it is worth checking whether the brief actually needs one.
The brief usually says "we want an app". Asked what it should do, the answer tends to be: show customers their orders and send them a notification. A website does the first. These days it does the second too, on most devices.
When a website is enough
A site that works properly on a phone is cheaper, changes faster and nobody has to install it. It handles sign-in, payments, forms and photos. A change is live the moment it ships — no store review, and no waiting for users to download a new version.
For a large share of briefs this is the right answer, especially when someone visits occasionally. Nobody installs an app they open twice a year.
When an app genuinely pays off
- It is used daily. An icon on the home screen earns its place when somebody reaches for it regularly — typically internal tools for field work, the warehouse or service teams.
- It needs hardware or offline operation. Continuous barcode scanning, Bluetooth devices, reliable work with no signal. These are the boundaries where the web genuinely stops being enough.
- Notifications are the point, not a bonus. When the whole value is that somebody learns about an event immediately and reliably.
- The app store is a sales channel. When people are meant to find you there and being present is part of the marketing.
When none of these holds, an app usually adds cost without adding value.
What costs more than expected
Budgets account for the build. The rest is where the surprise lives:
- Two platforms. iOS and Android mean testing twice, even when much of the code is shared.
- Releasing. Developer program accounts, reviews, rejections and resubmission. A fix in an app is not a deployment — it is a release.
- Old versions. A user who does not update is running last year's build. The backend has to serve both, which is a standing commitment.
- Forced updates. Operating system changes demand work even in a year when you change nothing in the app.
An app should not be an island
The most common architectural mistake is building an app with its own logic and its own source of data. You get a second system that drifts from the rest — a different price in the app than on the web, a different order state, a different login.
A well-built app is another client of the same backend: the same API, the same sign-in and permissions, the same rules. Logic belongs on the server, not least because anything inside an app can be taken apart and bypassed — a check on the client is not a check.
How we do it
We build mobile applications as part of a larger solution, against the same backend the rest of the system runs on. First, though, we work out whether you need one — and when the answer is that a website will do, we say so.
If you are weighing an app and want to go through it on a concrete brief, write to us. There is more about what we build on our services page.
Are you solving something similar in your company?
I want a free consultation