“We need an app” is a request we take seriously and challenge every time. Not because mobile applications are a bad investment — for some businesses they are the single most valuable system they own — but because the sentence usually describes a wish, not a decision.
The decision is: what does the user need to do, how often, and what is the cost of the friction between them and doing it?
What an app is good at
Native mobile applications earn their place when the use case has one or more of these properties:
- Frequent, habitual use. Daily or weekly interactions — a membership, a loyalty programme, a field team logging jobs — where the icon on the home screen is a real advantage.
- Device capabilities. Camera, location, offline use, push notifications that must arrive. A driver app, a site-inspection tool, an on-the-go ordering flow.
- A workforce in the field. Staff who work away from a desk, on their phones, all day. Here an app is not a marketing decision; it is operational infrastructure.
- A relationship that benefits from presence. A customer who returns monthly and values a one-tap rebook is worth keeping close.
What an app is bad at
- Occasional use. A customer who interacts twice a year will not install an app for it — and if they do, they will have to update it, remember the login, and find it again. A well-built web experience wins here every time.
- Acquisition. Prospects do not install apps to evaluate a business. The website does that job, and an app never will.
- Speed to market. Two platforms, two review processes, store policies, update cycles. Everything ships slower. If the business needs to learn quickly, that is expensive.
- Cost of change. Every improvement passes through app-store review and depends on users updating. A web system changes the moment you deploy.
The alternative that is usually right first
Most “we need an app” requests are really requests for self-service: let the customer book, pay, check status, download the document, without calling us. A modern web application — installable to the home screen, fast, working on every device — delivers that with no store, no updates and one codebase. It is also the right first step even when a native app will eventually make sense, because it proves the use case with real usage data.
How we decide
We ask four questions:
- Who uses it, and how often? Customers twice a year or staff twenty times a day?
- What does it need from the device that a browser cannot provide?
- What does it connect to? An app without a system behind it — CRM, scheduling, orders — is a front door to an empty room.
- What is the number that changes if this works — rebook rate, jobs logged per day, support calls avoided?
If the answers point to a native app, we build one, properly, for both platforms, connected to the systems that make it useful. If they point to a web application, we say so — and the budget goes further.
The goal is never “an app.” The goal is the outcome the app was supposed to produce.
