Web app, mobile app or both? How to choose
Ask for an app, need a web application: how to tell which you need, when both make sense, and how to avoid building two of everything.
The short answer
When a business says “we need an app”, it usually means “we need software our people or customers can use easily”. Most of the time that is a web application: it runs in the browser on any device, needs no installation, updates instantly for everyone, and is cheaper to build and maintain. A mobile app earns its place when the job happens away from a desk and depends on the phone itself: camera, location, notifications, long stretches without signal.
The choice is about how and where the work happens, not about what sounds modern.
The decision in one table
| Question | Points to web | Points to mobile |
|---|---|---|
| Where does the work happen? | At a desk, or on any device occasionally | In the field, in a vehicle, on a shop floor |
| How often does each user use it? | Weekly or less | Several times a day |
| Does it need the camera, location or sensors constantly? | No, or occasionally | Yes, as part of the core job |
| Must it work offline for long? | No, or briefly | Yes, for hours |
| Who are the users? | Staff at desks, customers who visit occasionally | Field teams, customers who use it daily |
| How fast must changes reach users? | Instantly | Store review delays are acceptable |
| What is the maintenance budget? | Modest | Larger, and yearly |
Count the right column. Zero or one: build a web application, make it work well on phones. Two or three: consider a progressive web app first. Four or more: a mobile app is justified, on top of a shared backend.
The three usual outcomes
- Web application only. Portals, dashboards, booking and quoting tools, internal systems, anything used at a desk or occasionally on a phone. The majority of business software.
- Progressive web app. A web application with installation, offline caching and notifications. Right for field forms with occasional gaps in coverage, customer tools used often, staff tools on shared devices.
- Web plus mobile. Back office at desks, field team or customers on phones with heavy device use. One backend, one set of rules, two front ends. The mobile side is often hybrid to keep one team on it.
One backend, always
Whatever the front end, the data, the business rules, the permissions and the integrations live in one place, behind an API. The web application uses it. A mobile app, if there is one, uses the same one. That is what keeps “both” from costing double, and what lets you add or replace a front end later without touching the core.
What this means for you
Describe where and how often the work happens, and run the table. A business lands on a web application that works well on phones, sometimes installable, and a mobile app only where the job truly lives on the device. Whichever you choose, insist on one backend. That decision is worth more than the choice of front end.
Frequently asked questions
Our customers are all on their phones. Does that mean we need a mobile app?
It means you need something that works well on a phone, which a modern web application does without an installation. A mobile app makes sense when customers use it often enough to want an icon, or when it needs device features the browser cannot reach. For occasional use, a link beats an install.
Can a web app work offline?
To a degree. A progressive web app can cache pages and data and queue actions until the connection returns. For occasional gaps in coverage that is enough. For a full day without signal with large amounts of data, a native or hybrid app is the safer choice.
If we need both, does the cost double?
No, if it is built properly. The backend, the data model, the business rules and the integrations are built once and serve both. The mobile front end is an additional screen layer on the same foundation. If a supplier quotes two full systems, the architecture is wrong.
Sources
- MDN Web Docs: Progressive web apps (accessed 2026-09-11)