A surprising number of projects begin with the wrong one of these chosen before anyone has asked why. Usually it is a mobile app, because that is the word people reach for when they mean software, and it is the most expensive of the three to build and the hardest to get anyone to use.
Here is how the three differ in ways that matter commercially, and the questions that tend to settle it.
What each one actually is
A website presents information. People arrive from search or a link, read, and take an action such as booking, buying, or enquiring. Most visits are the first one. Discovery is the whole game.
A web application is software in a browser. People log in, it remembers who they are, and they come back to do work. Discovery matters less because usage is deliberate and repeated.
A mobile app is software installed on a phone. It can send notifications, work offline, and reach the camera, location, and sensors properly. It also requires someone to visit a store, install it, and grant permissions before they receive any value at all.
The question that decides it
How often will one person use this?
Once or twice ever: a website. Weekly or monthly, with a login: a web application. Daily, or with notifications that genuinely need to interrupt someone: a mobile app.
The reason frequency dominates is the install. Asking someone to install an app is the most expensive request in consumer software, and you spend that cost before they have received anything. For something used twice a year, you will never earn it back. For something used every day, it is trivial and the app wins easily.
Four questions that resolve most remaining cases
- 01Do you need to reach people who do not know you exist? Websites are found through search. Apps are found through app stores, which are a far weaker discovery channel unless you already have an audience or a marketing budget.
- 02Do notifications drive the value? If the product only works when it can tell someone something at the right moment, that pushes strongly toward an app. Web push exists and is meaningfully less reliable, particularly on iOS.
- 03Does it need to work offline? Genuinely offline, not slow connection. Trains, basements, warehouses, remote sites. That is an app.
- 04Do you need the camera, precise location in the background, or sensors? Browsers can reach some of this, awkwardly. Apps reach all of it properly.
If none of those apply, build the web version. It costs less, ships sooner, is found by search, and can be used by someone the moment they click a link.
The cost difference is not what people expect
The build cost gap between a web application and a cross-platform mobile app is real but not enormous. The gap that matters is everything around it.
An app needs store accounts, signing certificates, privacy and data safety declarations, store listings, screenshots at multiple sizes, and a review process that can reject you for something not obvious in the guidelines. Every update goes through review, so a one-line fix is a release rather than a deploy. And you have to persuade people to install it.
A web application updates when you deploy it. There is no gatekeeper and no install. For a product still finding its shape, that difference in iteration speed is worth more than any technical advantage the app has.
The combination that usually wins
Most successful products end up as a website plus a web application: a fast marketing site that search engines and AI assistants can read, and the application behind a login.
If mobile is genuinely required, the sequence that works is to build the web application first, learn what the product actually is from people using it, and then build the app once the shape has stopped moving. Building the app first means discovering your product's real shape while paying store review costs on every correction.
Building app-only, with no web presence at all, is the mistake we see most often. Your entire discoverable surface becomes a store listing, and store listings do not rank for the questions your customers are actually asking.
A quick sanity check
- A restaurant, a clinic, an estate, a consultancy: website. Almost always. Discovery is the whole job.
- A booking system, a client portal, an internal tool, a dashboard: web application.
- A daily habit product, a messaging product, anything location-based, anything used while moving: mobile app.
- A marketplace or a SaaS product: web application first, app later if usage frequency justifies it.
If you are unsure, the cheaper answer is nearly always the right place to start. You can add an app to a successful web product. Recovering from an app nobody installed is much harder.