An app, or a website
Almost every business that asks for an app needs a website that works properly on a phone. The genuine exceptions are real, and they are recognisable inside ten minutes.
In short
The question is whether people will return often enough to justify an icon on their home screen. If the honest answer is a few times a year, build a website that works properly on a phone: an app adds two stores, two review processes and a permanent maintenance commitment while reaching fewer people. If they will use it weekly, need it offline, or need the camera, sensors or reliable notifications, an app earns its place. Most requests for an app are requests for a mobile experience that does not currently work.
The six real options
A responsive website
One codebase, no install, indexed by search engines and readable by assistants. The right answer for anything a person visits rather than uses.
A progressive web app
A website that installs to the home screen, works offline and can send notifications on most platforms. Covers a large share of what people actually wanted an app for.
A native app
Built for one platform, with full access to hardware and the best possible performance. Justified when the hardware or the frequency of use genuinely demands it.
One codebase, both platforms
A single build shipped to iOS and Android. Cheaper than two native apps and adequate for most business software, with real limits at the edges of performance and platform behaviour.
An internal tool, not a public app
A great deal of what gets scoped as an app is a tool for staff. That removes the stores, the reviews and the discovery problem entirely and it changes the build completely.
Neither, fix the mobile site
Before any of the above, look at what the current site does on a phone. Slow pages and forms nobody can complete on a small screen are frequently the whole of the problem.
Why most app projects were website projects
A large share of app projects were website projects that nobody re-examined after the first meeting. The request arrives fully formed, as an app, because that is the word people use for software on a phone, and the actual need underneath it is that the current site is unusable on one.
The install step is the thing that gets underestimated. Every install is a decision, and every decision loses most of the people in front of it. A website asks for nothing. An app asks for a store visit, a download, permissions and an account before anybody has seen a single thing of value.
That trade is worth making when people come back often. Weekly use justifies an icon, because the install is paid for once and the convenience is collected every week. Occasional use never repays it, and the app sits on a phone for a month before being deleted in a clear out.
The second underestimate is permanence. An app is not a project with an end. It is two platforms, two review processes and an operating system that changes underneath it twice a year. Something that has not been updated in eighteen months eventually stops working, and by then whoever built it has usually moved on.
Where an app is genuinely right, the signals are unmistakable and they show up in the first conversation. Field staff working without signal. A camera that has to read something. Notifications that have to arrive. Work somebody does every single day. None of those are close calls.
The pragmatic path for almost everyone else is to ship the mobile web version, watch what people actually do with it, and let real usage decide whether an app is warranted. That order costs less, answers the question with evidence, and leaves you with a marketing surface either way.
Website or app
Eight factors, read across. The first and the last row decide most cases, and both are about being found rather than about what the software can do.
| Factor | Website | App |
|---|---|---|
| How people find it | A search, a link, a message. There is no install step. | A store search or a link you send. There is always an install step, and most people do not take it. |
| Best for | Discovery, occasional visits, anything you want people to share. | Frequent use, logged in use, work somebody does every week. |
| Update cycle | You ship and it is live. | You ship, a store reviews it, then users have to update. |
| Hardware access | Camera and location with permission. No deep integration. | Camera, sensors, background work, and notifications that actually arrive. |
| Offline use | Limited, and achievable with effort. | Native to the format, and often the entire reason the app exists. |
| Cost over time | One codebase, one deployment, one thing to maintain. | Two platforms and two review processes, permanently. |
| Notifications | Possible, weaker on some platforms, easy to ignore. | The strongest return channel there is, and the easiest one to abuse until it is switched off. |
| Being found at all | Search engines index it and assistants can read and cite it. | Store discovery is close to zero without an existing audience or paid installs. |
Nothing here is about capability. Both can do most of what a business needs. The question is the install step and whether the frequency of use ever pays it back.
Five questions before you build an app
These take one meeting. Teams that answer them honestly either build something much smaller than planned or stop and fix the site instead.
- How often will one person open it in a month?Below about four, an icon on a home screen is not earned and the install step will lose you more people than the app gains. Weekly or more is the range where an app starts paying for itself.
- Does it need something only a phone can do?Background location, a sensor, offline work, reliable notifications, deep camera integration. If none of these appear on the list, the case for an app is thinner than it looks.
- Where do the first thousand users come from?Answer this before the build, not after it. Store discovery on its own delivers close to nothing. If the answer is your existing customers, that is legitimate, and it also means the app can be far smaller than planned.
- What breaks if a store rejects an update?Store review sits between you and your users forever. For anything that needs to change quickly, or that a platform might consider competitive with its own products, that is a strategic dependency and not a detail.
- Have you shipped the mobile web version first?It is faster to build, it tells you what people actually use, and it becomes the marketing surface either way. Teams that do this routinely discover the app they were about to build needed a fraction of its planned scope.
Questions we get
We were told we need an app to look credible. Is that true?
Credibility comes from the thing working, not from the format. An app with forty downloads and no recent update reads worse than a fast, well built site.
If the goal is to look serious, the money goes further on the site somebody actually lands on when they search your name.
What is a progressive web app, in plain terms?
A website that can be added to a home screen, opened like an app, work offline and send notifications on most platforms. No store, no install friction, one codebase.
It covers a large share of what people wanted an app for and it is worth ruling in or out explicitly before committing to a store build.
Should we build for iOS or Android first?
Whichever your users are actually on, which is worth checking rather than assuming, since it varies enormously by market and by sector.
If the split is close to even, one shared codebase across both is usually the better answer than sequencing two native builds.
How long does an app take?
Longer than the estimate, because store review, device testing and account handling absorb time that rarely appears in the plan.
The more useful question is what could ship in six weeks that would tell you whether the full thing is worth building.
Can we launch an app and a website at the same time?
You can, and it splits attention at the point where focus matters most. Both surfaces then launch at roughly seventy percent.
Ship the web version, learn from it, and let the app follow with a scope that reality has already narrowed.
What does an app actually cost to keep running?
Two developer accounts, periodic updates for operating system changes, and somebody who notices when a release breaks. It is a standing commitment rather than a one off.
Budget for the third year, not the first. The third year is where unmaintained apps quietly die.
Our competitors all have apps. Does that settle it?
Check their download counts and their last update date before concluding anything. A category full of neglected apps is evidence about the category, not about what you should do.
If theirs are genuinely well used, that is a real signal and it is worth understanding what people use them for.
What should we do first?
Open your own site on a phone and try to complete the thing a customer would want to do. Time it. That exercise settles most of these conversations in ten minutes.
If it is slow or the form cannot be finished, that is the project, and it is faster and cheaper than the one you were about to start.
More in the guides and every answer in one place.