Website, Web App, Mobile App or Desktop App: Which Do You Need?

'We need an app' is one of the most expensive sentences in software, because the word 'app' hides four quite different things: a website, a web app, a mobile app and a desktop app. They have different costs, timelines and trade-offs, and building the wrong one is a slow, painful way to learn the difference.

The good news is that the right choice usually falls out of a handful of practical questions about who will use it, where, and how. This is a guide to those questions, and to the cross-platform options that can save you from building the same thing several times over.

First, get the words straight

It helps to be precise about the four options before choosing between them. The distinctions sound obvious, but a surprising number of expensive disagreements come from people using the same word to mean different things.

• A website presents information: pages people read, like a brochure, blog or marketing site.
• A web app is software that runs in the browser and does work: dashboards, tools, accounts, anything interactive.
• A mobile app installs on a phone and can use the device fully: an icon on the home screen, offline use, notifications.
• A desktop app installs on a computer, for heavy or specialised work that suits a big screen and local power.

Two of these, the website and the web app, both live in the browser and are often confused, yet they pull in different directions: one is mostly read, the other is mostly used. Getting clear on which you are really building keeps a 'simple site' from quietly turning into a full application halfway through, which is exactly where budgets tend to disappear.

Who is your audience, and where are they?

Start with the people who will use it. A tool for your own staff at their desks points one way; a consumer product people reach for on the move points another. Where someone is when they need you, at a laptop, on a phone between meetings, or on a shop floor, often decides the answer before any other factor gets a look in.

It is worth watching real people rather than imagining them. Where do they already do this work, and on what device? A field team logging jobs from a phone, an analyst living in spreadsheets on a laptop, and a customer browsing on the sofa each point to a different answer. Build for the context they are actually in, not the one that is easiest to picture.

Do you need to work offline or use the device?

Two practical questions cut through a lot of the debate. Does it need to work without a connection? And does it need deep access to the device: the camera, GPS, push notifications, sensors? If the answer to either is yes, you are leaning toward a mobile or desktop app. If your software is happy online and in a browser, a web app is usually faster and cheaper to build and maintain.

Modern web apps blur this line more than they used to: they can cache data, send notifications and behave well on a phone without ever touching an app store. So the real question is not whether something would be nice to have natively, but whether the offline use or device access is essential to the core experience. If it is not, the browser usually wins on cost and reach.

How will people find and install it?

Distribution shapes the decision more than people expect. A website or web app is reached with a link and works everywhere instantly, with nothing to install and updates that ship the moment you deploy. A mobile app lives behind an app store, with its review process and its rules, in exchange for a place on the home screen and access to the device. A desktop app is installed directly and suits controlled or specialised environments. Each path has a cost, and it is rarely just the build.

Updates deserve a thought here too. A web app updates the instant you deploy, so everyone is always on the latest version. Mobile and desktop apps depend on users updating, or on stores approving releases, which means you can be supporting several versions at once. That long tail of old versions is a real, recurring cost that is easy to forget on day one.

What is your budget and timeline, honestly?

Every additional platform is, roughly, another product to build, test and maintain. A web app reaches every device with a single codebase. Native mobile and desktop apps add real cost, not only to build but to keep alive as operating systems change underneath them. Being honest about budget early prevents the classic trap: committing to apps on every platform, then maintaining none of them well.

Maintenance is the part that catches people out. A build has an end date; an app does not. Operating systems change, libraries age, security issues appear, and each platform you support needs ongoing attention to stay healthy. It is far better to do one platform properly than to spread a thin budget across three and watch all of them slowly decay.

Cross-platform options that save you building twice

You do not always have to choose one and abandon the rest. Mature cross-platform tools let you share most of a codebase across targets, which can be the pragmatic middle path.

• React Native lets you build mobile apps for both iOS and Android from largely shared code.
• Electron and Tauri let you build desktop apps using the web technologies your team likely already knows.
• A web app remains the broadest reach for the least effort, and is often the right first move.

These are not free, every platform you ship to is still something to support, but they can turn 'build it three times' into 'build most of it once' and let you pick your battles from there.

The right answer is almost never all of them at once. It is the one type that reaches your real users, where they are, within a budget you can sustain. Working through that decision clearly, before a line of code is written, is exactly the kind of question our engineering and consulting work is there to help you answer.