The request almost always arrives the same way. Somebody has decided they need an app, and what they want from me is a number.
So I ask what it is for. Maybe half the time, the answer describes something a website already does, with a download bolted onto the front of it.
This is not an argument that apps are a waste. I build them and I publish my own. It is an argument for answering one question before anybody writes code, because getting it wrong costs more than the build and is hard to walk back.
What an app gives you that a website cannot
Start with the honest list. There are things only a native app does, and if you need any of them the rest of this article does not apply to you.
- A permanent place on the home screen, seen dozens of times a day whether or not it is opened.
- Push notifications that arrive reliably, on your schedule rather than the visitor’s.
- Real offline use, not a cached page but full function with no signal at all.
- Deep device access: Bluetooth pairing, background location, health data, the camera under your own controls, secure on device storage.
- Performance for heavy work, like continuous graphics, a large local database, or media capture and editing.
- A listing in a store the customer already trusts and has a payment method set up in.
If your idea needs two or more of those, stop reading and go build the app. The rest of this is for everyone else.
What it costs that a website does not
The build is the part people price. It is rarely the part that hurts.
You are shipping to two platforms, not one. iOS and Android are separate products with separate release processes, and a cross platform framework does not remove that, it just moves the cost into working around the places where the abstraction leaks. Every release goes through store review, which is a queue you do not control and a set of rules that are interpreted by a person. I wrote about what that whole chain actually involves in everything an App Store launch needs besides the code, and about the cost of getting it wrong in what a rejection actually costs you.
Then the app has to stay alive. There is an annual developer program fee, which is the smallest line on the list and the one everyone remembers. The real recurring cost is that the ground moves. A new version of iOS lands every autumn. Signing certificates expire. APIs get deprecated and then removed. None of this is caused by anything you did, and all of it lands on you anyway. An app nobody maintains does not sit there quietly, it eventually gets pulled from the store for being too far out of date.
There is a version problem too. When you fix something on a website, every visitor has the fix the moment you deploy. When you fix something in an app, you have the fix, and your users have it only once they update. For a while you are supporting both.
Before you commission any of it, be clear on what you end up holding at the end. Source code, the store listing, the signing identity and the developer account itself are separate things and they do not automatically travel together. That is the same question I raised about websites in what you actually own when you hire someone to build your website, and it matters more here, because an app you cannot sign is an app you cannot update.
The install is the cost nobody prices
This is the one that quietly kills most small business apps, and it has nothing to do with how good the app is.
A website asks for one tap from a search result. An app asks somebody to find it in a store, agree to install it, wait for the download, open it, usually create an account, and then remember it exists a month later. Every one of those steps loses people, and they compound.
So the question is not whether people would like your app. It is whether they will use it often enough to justify the space it takes up. Frequency is the whole game. An app somebody opens twice a year gets deleted the first time their phone runs low on storage, and it is not coming back.
A restaurant most people visit twice a year does not need an app. It needs a mobile site that loads in under two seconds and a phone number that dials on the first tap. That is a much smaller project, and it is the one that actually gets used. I went through what matters on a phone, as opposed to what people assume matters, in responsive is not a feature.
Three questions that settle it
When somebody asks me this, these are the questions I ask back, in this order.
- Will the same people use it more than once a week? Frequency is what pays back the install. Not total users. The same people, coming back.
- Does it need something only the device can do? Go feature by feature. If every one of them works in a browser, what you are describing is a container, and you are paying for the container.
- Are you prepared to fund it every year? Not can you afford to build it. Can you afford to keep it current in year three, when it has not made you any money yet.
Two yeses and it is probably an app. One yes and it is probably a website. No yeses and it is definitely a website, and somebody is about to sell you one anyway.
When the answer is genuinely yes
Plenty of times it is, and the same logic that rules an app out for a restaurant rules it in elsewhere.
Field crews logging work in places with no signal need the app, because the offline requirement is not negotiable. A shop people visit weekly can carry ordering and loyalty in an app and see it opened constantly. Anything that pairs with hardware over Bluetooth has no web equivalent worth discussing. Anything that has to notify somebody reliably, rather than hoping they check, has to be an app.
Internal tools are the clearest case of all, because the install problem disappears. When the users are your own staff, you can simply require it, and the daily use is guaranteed by the job rather than hoped for.
In all of those, the app is not a nicer website. It is the only thing that does the work.
The option in between, which most people have not considered
A modern mobile site can be saved to the home screen, run full screen with no browser chrome, cache enough to keep working on a bad connection, and on current versions of both iOS and Android send push notifications once somebody has added it and allowed them. It gets you a surprising amount of the way there.
It will not give you a store listing, purchases through the store, or the deeper device access. Be clear eyed about that. What it gives you instead is one codebase, no review queue, a build measured in days rather than months, and every user on the current version the instant you ship. For a lot of the requests I get, that is the right answer, and it is part of ordinary web design and development work rather than a separate project.
The useful move is to build that first and watch what people actually do with it. If the usage is there and the frequency is real, you now have evidence rather than a hunch, and the app is a much safer thing to commission.
What I would ask you
If you are weighing this, the conversation worth having is not about price. It is about how often the same person would open it, and what happens on their phone that could not happen in a browser. Those two answers decide it, and they take about ten minutes.
If the answers point at an app, that is work I do and I will tell you what the first year really looks like rather than just the build. If they point the other way, I will tell you that too. Either way, tell me what you are trying to fix and we can work out which one it is.
