Do you actually need a mobile app?

A native app is the most expensive thing most small businesses ask us to build, and it is the request we most often talk people out of. Not because apps are bad — because the reason given is usually one a website already solves, at a fraction of the cost and without a review queue between you and every change.

The reasons that do not justify an app

"We want to be on the App Store." That is a distribution channel, not a customer need. Nobody browses an app store looking for a local business the way they browse a map or a search result. Being listed there is not the same as being found there.

"Our website is hard to use on a phone." That is a website problem, and fixing it costs a fraction of an app. It is also a problem you will still have after the app ships, because most of your traffic will keep arriving on the web.

"Our competitor has one." Look at their reviews and their update history before you copy them. An app that was last updated three years ago and has eleven ratings is not a competitive advantage; it is a monument to somebody's budget.

The reasons that do

You need something a browser cannot reach, or cannot reach well. Reliable background location. Bluetooth hardware. Genuine offline use somewhere with no signal. Sustained camera work. These are real limits, and if you are against one, the decision makes itself.

You need push notifications that people actually want. The test is whether a customer would be annoyed to miss the message. Order ready, driver arriving, shift published, result available — yes. Marketing — no, and they will turn notifications off within a week, after which you have an app with no channel.

Or you have customers who use you weekly rather than twice a year, and an icon on the home screen genuinely removes friction.

Frequency is the strongest single signal. Apps earn their place through habit. Without habit, an app is a website that is harder to update and requires someone else's approval before every change.

The middle path most people have not been shown

A modern mobile website can be installed to the home screen, work offline, cache data, and look exactly like an app — with no store listing, no review queue and no separate build for each platform.

For a large share of what businesses ask for, that is the honest answer: the same result, sooner, for less, and you can change it on a Tuesday afternoon without asking anyone's permission.

It is not a free lunch. Push notifications are more limited, hardware access is narrower, and there is no store listing to be found in. But if you read the previous section and none of it applied to you, none of those limits will bite either.

What an app actually costs over three years

The build is the part people plan for. The rest is not.

Two platforms rather than one, unless you accept a cross-platform framework and its trade-offs. Developer accounts on both stores, annually. Operating system updates every year, some of which break things. Devices to test on. And a maintenance budget at a meaningful fraction of the build cost per year, forever, because an app nobody maintains stops working within about two years — quietly, in a way you usually hear about from a customer.

A useful discipline: take the build quote, add three years of that maintenance, and ask whether the case still holds at the larger number. If it only works at the build price, it does not work.

What the browser can and cannot do, specifically

Vague claims about apps being "more powerful" are not much help, so here is the line as it actually falls.

A mobile website can already use the camera, read location while the page is open, work offline against cached data, be installed to the home screen with your icon, and take payment through the phone wallet. That covers most of what a small business needs.

What it cannot do well is run in the background. Location tracking after the page is closed, Bluetooth to a specific device, notifications that arrive reliably on every platform, and anything needing sustained access to the camera or sensors while the user is elsewhere. If your case lives in that list, the app is justified and the decision is easy.

The list moves, slowly, and it moves in the browser's favour. Several things that required an app five years ago no longer do. It is worth asking the question again rather than relying on what was true the last time somebody quoted you.

What happens to it when the developer moves on

An app is more fragile than a website in one specific way: it cannot be handed over casually.

A website can be picked up by almost any competent developer with a login. An app needs the source code, the signing certificates that prove new versions come from you, and the store accounts in your business name. Lose the signing key and you cannot publish an update to your own app — the store will treat the replacement as a different product, and your existing users simply stop receiving updates.

So the questions to settle before anyone writes code are dull and decisive. Where does the source live, and do you have access to it today? Whose name is on the developer accounts? Who holds the signing keys, and is there a second copy somewhere you control?

This is the most common way small-business apps quietly die. Not a technical failure and rarely a dispute — just a developer who moved on, taking the only copy of something nobody thought to ask about.

A reasonable way to decide

Start with the mobile web version. Measure how often people come back. If a meaningful group returns weekly and starts asking for something the browser cannot do, build the app — and build it knowing exactly which feature justified it, which also tells you what to build first.

That sequence costs less, ships sooner, and replaces a hunch with evidence. The alternative is a six-figure commitment made on the strength of a competitor's app you have not looked at closely.