Mobile app, web app, or a bot?
Three questions to answer before commissioning an app — and what each option really costs to keep alive.
A large share of the requests we receive start with "we want a mobile app." By the end of the conversation, about a third of them really are apps; the rest get solved as a web experience or a bot, and the client ships faster and cheaper.
Making that call early is worth more than months spent on the wrong side of it. Three questions decide almost all of it.
1. How often will someone open this in a month?
The most expensive part of an app is not building it — it is getting it installed. You are asking someone to visit a store, give up storage, grant notification permission, and keep your icon on their screen. There has to be something in return.
A rough threshold: if a user will open it less than a few times a month, an app is probably the wrong answer. An app downloaded once a year to track an order gets deleted before its second use, and you keep paying to maintain it.
What justifies an app is either frequency or a capability that belongs to the phone itself:
- Camera, location, offline use, background notifications
- Field teams — warehouse, courier, service, stock counts
- A function that needs to be reachable from the lock screen
Without any of those, a web experience designed for mobile usually serves the same need better: the link is shareable, updates do not wait for store review, and nobody installs anything.
2. Are you solving a repeated question, or a task?
This is the line between a bot and an app.
If it is a question — where is my order, when are you open, what does it cost, can I book a slot — the answer belongs in chat. Your customer is already on WhatsApp; you do not need to put a new app there. On the bot side we typically build a flow on the WhatsApp Business API, an AI-assisted answer layer for the long tail of questions, and a clean handover to a human at the point the bot cannot resolve.
If it is a task — a multi-step form, a checklist, a measurement entry, a signed handover — a chat window becomes exhausting. You need a screen. But that screen does not have to be an app, which is what the third question settles.
3. Who uses it: your customer, or your team?
This is the question that determines where the money goes.
If your customer uses it, install friction is your problem. Every extra step costs users, and the app has to be opened often enough to earn back what it costs to keep alive.
If your team uses it, install friction disappears — you own the devices and you do the setup. An app is far easier to justify here: offline work, barcode scanning, location stamps are precisely where the web is weakest. Internal apps tend to be smaller, longer-lived, and much clearer to measure.
What the three options actually cost
Comparisons usually happen on the first delivery price. The real difference shows up after year one.
Mobile app. Two platforms, two store accounts, two review processes. Operating systems update annually, and even if you change nothing, the app has to be rebuilt and resubmitted. There is no "finished" state: as long as it is published it carries a small but uninterrupted maintenance line. In exchange, you get the full capability of the device.
Web built for mobile. One codebase, no store review, updates live the same day. Notifications and offline support are limited, though no longer impossible. For most consumer scenarios this is where to start — you move to an app once usage is real, not the other way round.
Bot. The cheapest of the three and the fastest to launch, but narrow in scope. Rule-based flows are predictable, AI-assisted answers are flexible, and you need both. What a bot measures is valuable in itself: it shows you, with data, which questions actually repeat. If you later commission an app, that data is the best source for scoping it.
How we sequence it
The order is close to identical on every project:
- Measure. Do not write code before you can see the demand. A dump of the questions already arriving through your existing channel usually writes the first scope for you.
- Ship the cheapest form. A bot, or mobile web. The goal is not a perfect product; it is observing behaviour.
- Watch frequency. Once usage settles and a real device capability is needed, an app becomes a defensible investment.
- Keep the app narrow. Do not reproduce everything the web already does; move over only the work that is genuinely better in an app.
This sequence removes the trap that "app first" projects fall into most often: taking on the maintenance of a product, after months of development, that nobody installed.
If you are not sure which side your own need falls on, the work we do on the bot and mobile app side starts with exactly that distinction.