Does your business need a mobile app: three conditions that make it pay off
We shipped our own app to a store: an alarm clock and sleep routine tracker. It runs locally with no account, and it has a handful of users. Not because it is badly built. The technical core is the hard part there, since the onboarding has to route around battery optimisation with deep links for roughly fifteen device manufacturers, otherwise the alarm does not fire.
The reason is different. An app does not create demand. It serves demand that already exists.
That is the thing worth understanding before the build decision. Below are the three conditions under which an app pays off, and what you pay after release no matter the outcome.
Condition one: the scenario repeats often
Apps live on repetition. Installation costs the user effort, and that effort is only repaid when they come back.
A good example from our work is a system for a college. A mobile app and a web platform run together: schedules and announcements live in the app, while points, reports and rankings live on the web. The app is justified because schedules are checked daily, while reports are opened once a month from a desktop. The system has been in production for over a year, with roughly 99 percent of students covered by the points system.
The test is simple. If a person will open your product less than once a week, they do not need an app. They will not remember it is installed.
Condition two: device capabilities or offline work
This is what a website does not give you. Camera and file processing, background location, working on a plane or in a basement, notifications as a channel you own.
In an app for drivers that saves your parking spot and warns you before the time runs out, offline is not a convenience but a precondition: there is no signal in an underground car park, and without offline the product is useless exactly where it is needed.
A separate word about notifications. They are often the main argument for building an app, and that is only half true. You do get a channel, and you pay for it with attention: one unnecessary notification a week and the user turns them off for good, after which the channel is gone and the app remains.
Condition three: somebody to come back
The least comfortable condition. An app does not bring people on its own.
App stores give some search driven flow, but it is not an acquisition channel in the way a website with organic traffic or an existing messenger audience is. The store page for another of our products collected 1,071 views and 26 preorders between 25 August and 16 September 2026 with no promotion, which is a decent result for a zero budget and shows the order of magnitude: tens of people, not thousands.
So the question «where do the first hundred users come from» is answered before development, not after release. Without an answer, the app will work perfectly and stay empty.
What you pay after release
The line that is usually missing from the calculation.
Platform updates. Operating systems change their requirements, and an app nobody has touched for a year eventually stops building or disappears from the store.
Store rules. Requirements for permissions, privacy and listings change, and that is mandatory work rather than your own roadmap.
Two platforms, if you support both. A cross platform stack reduces the volume without eliminating it: testing and releasing still happen twice.
Reviews and rating. The first ratings cannot be rewritten and recent ones weigh more, so launching on a raw build costs more than delaying by two weeks.
A website is calmer on every one of these points, because there is no intermediary between you and the user.
When a website is enough
When the scenario is one off or rare: an enquiry, a price calculation, a booking, evaluating an offer.
When you need search traffic. Apps are not indexed, so the entire organic flow stays with the website.
When the product is unproven. A website with a form and manual processing produces the same demand signal several times cheaper and faster.
Between those two poles sits a third option, a mini app inside a messenger: it removes installation and registration and works well on short paths, but gives you no offline. We wrote about it separately.
How to test the decision before building
Count the frequency. How many times a week will one person open the product. Not «could open», will open.
Find the scenario that does not work without an app at all. If there is none, the app is a convenience rather than a necessity, and conveniences almost always lose on payback.
Test demand cheaply. A store page with preorders, a form on the site, even a direct question in your own channel gives you a signal before the budget is spent.
And decide in advance at what numbers you will call it a failure. A threshold written before the start is cheaper than any discussion after the fact, because it removes the main temptation: explaining a weak result by saying you just need to wait one more month.
FAQ
Which is cheaper, a mobile app or a website
A website, both to build and to keep running: no app stores, no release reviews, no second platform. The build difference is usually several times over, and the maintenance gap widens, because an app has to be updated as operating systems change.
Can we start with a website and add an app later
Yes, and that is the normal order. The website tests demand and brings search traffic, and the app makes sense once you can see people returning to the same scenario regularly. The reverse order costs more and more often ends with an app that has no users.
What does it cost to maintain an app after release
Budget for the mandatory minimum, not only for improvements: updates for new operating system versions, changing store requirements, replying to reviews, and crash monitoring. That minimum exists even in months when you ship nothing.
Does a messenger mini app replace a mobile app
Partly. It removes installation and registration and suits short scenarios, but it gives you no offline mode and no heavy device work. If the scenario fits a short path, the mini app usually wins.