Do you need an app, or just a fast mobile site?

“We need an app” is one of the most common opening lines we hear, and it is almost never wrong about the underlying problem. Something is genuinely too slow, too manual, or too hard for customers to reach. An app is just the shape the frustration arrives in.

But an app is a much bigger commitment than a website, and a large share of the businesses that ask for one would be better served by a fast mobile site or a web app. That is not us talking anyone out of work — it is on our own app development page, in the FAQ, in writing. This post is the long version of why.

The three things people mean by “app”

The word covers three quite different projects, and conversations go wrong when two people in them mean different ones.

A native app. Built for Android and iOS, installed from a store, sits on the home screen. Can use the camera, GPS, Bluetooth, fingerprint sensor. Can send push notifications. Works offline.

A web app. Opens in the browser at a normal URL, but behaves like software rather than a brochure — you log in, you have your own data, things update without reloading. A customer portal, a dashboard, a booking system. No store, no install, no approval.

A fast mobile site. A normal website that happens to be quick and pleasant on a phone. No accounts, no state, nothing to install.

These are ordered by cost, roughly, and the gap between the first and the other two is much wider than it looks — because a native app is not one build, it is two, plus the machinery around them.

The costs a native quote often leaves out

The build price is the part everyone compares. The parts that surprise people come afterwards.

It is two codebases, or one with two sets of problems. Android and iOS behave differently enough that “we’ll do both” is rarely half again — it is closer to double, unless you deliberately choose a shared codebase and accept the trade-offs that come with it.

Store accounts and fees. Apple’s developer programme runs on an annual fee, Google Play on a one-time registration. Small numbers next to a build, but they are ongoing obligations with renewal dates, and if they lapse your app disappears.

Review, every single time. Every update goes through Apple’s review before your users see it. A typo fix on a website is live in a minute. A typo fix in a native app is a submission, a wait, and a version your users have to actually install.

Users who never update. This is the one that quietly bites. Some meaningful share of your install base will be running a version you shipped a year ago, so your backend has to keep supporting it. On the web, everyone is on the current version by definition.

OS upgrades you did not ask for. Android and iOS ship yearly. Things break. An app with nobody maintaining it degrades on its own, without a single line of your code changing — which is exactly how we end up being handed apps that “just stopped working”.

None of this makes native the wrong choice. It makes native a commitment, and it should be entered knowing the second-year cost, not just the first invoice.

The question that decides it more often than any other

Here it is: how often will one person use this?

Not how many people. How often, each.

An install is a real cost to your customer. They have to find the store, wait for a download, give up storage, and then keep an icon on their phone. People pay that cost willingly for things they use weekly — their bank, their messages, their ride-hailing app. They do not pay it to book one appointment, check one order, or read your prices.

So if the honest answer is “a customer will use this a few times a year”, an app is asking for an install they will not do, in exchange for a build you will pay for twice. A fast mobile site meets them at a link. Which is what they were going to tap anyway.

If the honest answer is “several times a week, by the same people” — staff, subscribers, drivers, members — the install cost gets amortised, and native starts to earn its place.

When you genuinely need native

There is a short list, and it is worth knowing because these are the cases where a web app really will not do:

• Push notifications you depend on. Web push exists and works, but support and reliability across phones is uneven enough that if notifications are the product, native is the safer ground.
• Real offline use. Not “loads a cached page” — genuinely working through a delivery route or a stock count with no signal, syncing later.
• Device hardware. Continuous camera work, Bluetooth peripherals, background location, biometric login.
• The store itself is the channel. If people will discover you by searching the App Store, then being in it is the point, and no website substitutes for that.
• Performance beyond what a browser gives you. Games, heavy graphics, real-time media.

If nothing on that list is true of your project, you are choosing native for reasons of feel and status rather than capability — which is a legitimate thing to want, but should be priced and named as such.

The middle option people forget

A web app can be installed. Modern browsers let a site be added to the home screen, run without browser chrome, cache itself for offline use, and look very much like an app once it is open.

It is not the same as native — the hardware access is narrower and the install prompt is less prominent — but it covers a surprising amount of the middle ground: one codebase, no store review, updates that reach everyone immediately, and a link you can send in a WhatsApp message.

For a customer portal, a dashboard, an internal tool, or a booking flow, this is very often the right answer, and it is the one that gets skipped because it does not have a marketing department.

How to decide, in order

Answer these four, honestly, before anyone quotes anything:

1. How often will one person use it? Rarely → site. Weekly → app territory.
2. Do you need hardware, real offline, or dependable push? If yes, native. If no, that removes the main technical argument.
3. Who are the users — the public, or a known group? A known group (staff, members, existing clients) will install things. The general public mostly will not.
4. Can you fund year two? An app with no maintenance budget is a liability with a launch party.

If the answers point at a website, build the website properly — fast, works on a real phone, easy to use one-handed — and revisit the app when you have usage data telling you people want one. That is a much better basis for the decision than a hunch, and it costs a fraction to find out.

What we do about it

We say which one your case is on the scoping call, including when it is the smaller project. That is not generosity; it is self-interest with a longer horizon. An app nobody installs is a bad outcome we would have been paid for, and it is the kind of outcome people remember out loud.

If you are somewhere in this decision, send us what you are trying to make possible — not what you want built. We will tell you which of the three it actually is, and roughly what each would cost, before anyone commits to anything. App development and web development are the two pages worth reading next, depending on where you land.