Do you need an app, or a better website?
Most businesses that ask us for an app need a faster, clearer website instead. Build an app when people will open it repeatedly, when it needs something only a phone has, such as the camera, location, offline use or push notifications, or when it is a tool for your staff rather than your customers. If someone would visit once a year, an app is an expensive way to be ignored.
Why the question comes up at all
Nobody wakes up needing an app. They want something else and an app looks like the way to get it. Usually one of three things: customers keep ringing to ask the same question, the website feels slow and old on a phone, or a competitor has one and it looks serious.
Only the third is really about apps, and it is the weakest reason of the three. The first two are usually fixed better, faster and for less by improving the site you already have. So the useful first question is not "what would the app do", it is "what is going wrong now, and for whom".
What an app can do that a website cannot
The list is shorter than most people expect, and it is worth knowing precisely, because everything else can be done on the web.
- Work properly offline. An engineer in a basement, a driver in a rural spot, a coach at a poolside with no signal. Websites can cache a little; apps can work for a whole shift and sync later.
- Push notifications that arrive reliably. Web push exists and works, but it is weaker on iPhones and people grant it far less often.
- Deep access to the device. Continuous location in the background, Bluetooth hardware, barcode scanning at speed, secure local storage of credentials.
- A place on the home screen. Not a technical capability, a habit one. If your service is genuinely used weekly, that icon is worth real money. If it is used yearly, it is clutter.
If none of those four appear in your answer, you are describing a website.
The test: how often will someone open it?
Ask how often a single person would use the thing, and be honest rather than optimistic.
Daily or weekly is app territory. Parents checking a lesson timetable, staff logging jobs, customers with a running account. The install is paid back many times over.
Monthly is arguable, and usually depends on whether the person has a relationship with you or is shopping around.
A few times a year is not an app. Asking someone to visit a store, download 40MB and create an account in order to book a skip once is a larger favour than most people will do. They will use the website instead, or a competitor's.
Staff tools break this rule, and they are the case people most often overlook. An app used by twelve of your own people, every day, in places with bad signal, is frequently the strongest business case in the room and nobody had thought of it.
App and mobile website, side by side
Neither is the better option in the abstract. They cost differently, they are found differently, and they fail differently.
| Mobile website | Mobile app | |
|---|---|---|
| How people find it | Search, a link, a QR code | They must already know to look in a store |
| Getting started | One tap, they are in | Store listing, download, often an account |
| Works offline | Barely | Yes, properly |
| Notifications | Weak on iPhone, low opt-in | Reliable, if people allow them |
| Updating it | You publish, it is live | Submit, wait for review, users must update |
| Platforms to build | One | iOS and Android, plus a web version for everyone else |
| Best for | Being found, being read, one-off jobs | Repeat use, staff tools, anything offline |
The options in between
The choice is not binary, and the middle ground is where a lot of our clients end up.
A mobile-first website is not a compromise. Done properly it loads in a second, works on any device, needs no install, and can be added to a home screen by anyone who wants it there.
A progressive web app goes further: installable from the browser, works offline to a degree, no store review, one codebase. It is a good fit when you want app-like behaviour for a logged-in group of users but do not need deep device access.
And you can start with the website and add the app later, once you know from your own numbers who is coming back and what they do. That order round costs less and tells you more. The other way round, you find out after you have paid for it.
If you do build one, start smaller than you think
The apps that work do one job that a person needs often. The apps that do not are the ones that tried to be the whole business on a small screen.
Pick the single thing your users would do most, build that properly, and put it in real hands. You will learn more from a fortnight of ten people using one screen than from six months of building twenty. The features you were sure about will go unused and something you nearly cut will turn out to be the point.
Practically: we scope the first version to the smallest thing that is genuinely useful, price it fixed and in writing, and agree what the second version depends on before starting. If the frequency is not there, we say so on the call. Talking somebody out of an app costs us a project and saves them a great deal more.
Common questions
Neither is better in the abstract. A website is better for being found, for one-off jobs and for anyone who has not heard of you: it takes one tap and no install. An app is better for people who come back weekly, for anything that must work offline, and for tools your own staff use. If someone would use it a few times a year, build the website.
It depends on how many screens there are, how much has to work offline, whether it needs a back office behind it, and whether it ships on iOS, Android or both. What we can say is how we quote: after a discovery call we put a written scope and a fixed price in front of you before anything is built, so the number is specific to your app rather than a range.
Look at what your own customers use rather than the national split, because it varies enormously by sector and by price point. If the audience is genuinely mixed, cross-platform frameworks such as React Native or Flutter let one codebase serve both, which usually costs less than two native builds and is what we recommend for most business apps.
Sometimes, and it is worth asking before assuming a rebuild. A progressive web app can be installed from the browser, works offline to a degree and needs no store review. It will not give you deep device access or reliable notifications on an iPhone, but for a logged-in group of users it often does the job at a fraction of the cost.
It needs maintaining, and that is not optional in the way it can be for a website. Operating systems update, store policies change, and an app left alone for two years will usually stop working. Budget for it from the start, and ask any developer what year two costs before you commit to year one.
Where to go next
If you want a straight answer about your own situation, tell us what you are trying to do and we will say what we would do, including when the answer is that you do not need us. Start a conversation.