You may not need an app. Here's how to tell.
"We need an app" is sometimes exactly right and sometimes a way of saying we want to be taken seriously. Four common beliefs are worth checking before you pay to build and maintain two of them.
Build a native mobile app when the same people use your product often, away from a desk, and need what a phone does best: dependable offline work, heavy camera or scanner use, background sync, hardware connections, or notifications they actually want. If most people visit occasionally, arrive from search or a link, and need an answer or one transaction, a well-built mobile website, possibly an installable web app, usually serves them better and costs less to keep up.
Where the question usually starts
Someone on the leadership team says it in a meeting. "We should have an app." Sometimes a competitor just launched one. Sometimes a customer asked. Sometimes it just feels like what a serious company has.
It's a fair instinct, and sometimes it's exactly right. But an app is a big commitment: two platforms, two stores, updates people may never install, and a second product to support for as long as anyone has it on their phone. A mobile website can be a very different amount of work.
So before anyone writes a brief, it's worth checking the beliefs that usually sit underneath "we need an app." Here are the four we hear most, and what tends to be true instead.
Belief: customers expect an app
What's usually true: some customers do, and they're the ones who come back often.
Think about who uses your product, and how often the same person returns. Someone who orders supplies from you every week, books a class three times a month, or does their whole job through your tool may love an app. It's one tap away, it remembers them, and it can work the way they work.
Someone who visits twice a year to check an order, pay a bill, or find opening hours wants the opposite. They arrived from a search result or a link in an email. Asking them to install something before they can do one small task is a toll, and many won't pay it.
Most businesses have both groups. The mistake is building one product for both. Ask a simpler question first: what share of the people you care about would open this thing every week? If the honest answer is "a small group," that group might deserve an app, and everyone else deserves a fast, clear mobile site.
Decision guide
Where each one tends to fit
| Consideration | Mobile website or web app | Native app |
|---|---|---|
| How often | Occasional visits: a check, a payment, a booking. | The same people, every week or every shift. |
| How they arrive | From search, an email link, or a QR code. | From the home screen, by habit. |
| Offline | A dropped connection is an inconvenience. | A full day of work has to run without signal. |
| Device features | Camera, location, and push on most platforms. | Heavy scanning, Bluetooth hardware, background tasks. |
| Updates | Everyone gets the new version on their next visit. | Store review, and old versions to support. |
An app earns its place on someone's home screen by being used. Being downloaded isn't the same thing.
Belief: an app is the website in a wrapper
What's usually true: an app is a second product with its own life.
It needs to pass app store review. It needs updates when Apple and Google change their operating systems, which they do every year. And here's the part that surprises people: old versions stay out in the world. Some users never update, so the systems behind your app have to keep answering requests from versions you shipped a year ago, or you have to decide when to cut them off and how to tell them.
None of that is a reason not to build. It's a reason to budget for year two, not just launch. If nobody can name who will own the app after it ships, that's the answer to the question for now.
There's also the matter of being found. A web page can be reached from a search result, a link in a text message, or a QR code on a counter, in one tap. An app has to be found in a store, installed, opened and signed into before it can help. For the occasional visitor, every one of those steps loses people.
A website changes when you deploy it. Everyone gets the new version on their next visit. For many products, that alone is worth a lot.
Belief: the web can't do what we need
What's usually true: the web can do more than most people assume, and a few things it still can't do well.
A modern mobile site can use the camera, ask for location, work as an installable app on the home screen, and send push notifications on most platforms. On iPhone, that last one arrived with iOS 16.4 for web apps added to the Home Screen. For a lot of businesses, an installable web app covers what they imagined an app would do.
Native still earns its place in specific situations:
- Dependable offline work. A crew in basements and rural sites who need a full day's jobs, photos, and forms to work without a signal, and to sync cleanly later.
- Heavy scanning or camera work. Barcode scanning all day, document capture, or anything where speed and reliability on the device really matter.
- Hardware. Bluetooth printers, scales, sensors, card readers.
- Background work. Tracking a route, syncing quietly, or reacting to something while the app isn't open.
If your list of must-haves includes these, native is probably right. If it doesn't, ask why the app is on the table.
Belief: we have to decide everything now
What's usually true: you can defer the app. You can't defer where the data lives.
The decision that's expensive to change isn't web versus native. It's whether the systems behind your product are built so more than one front end can use them. If your business logic lives in a website's pages, every future app means rebuilding it. If it sits behind a clean set of services, a mobile site today and an app for your heaviest users later are both reasonable steps.
This also makes the split audience easy. A field team, a warehouse crew, or a set of power users can get a native app built for their day, while customers get a mobile site that works from the first tap. Same records, two front doors.
How the work moves
Answer these before you commit
- Count the weekly users
Who comes back often enough to keep an app?
- Picture where they are
Desk, couch, van, ladder, or warehouse aisle.
- Name the offline task
The specific job that has to work without signal.
- Write three useful notifications
Messages a user would thank you for.
- Name the year-two owner
Updates, store review, old versions, and support.
A test you can run this week
Pull up your own numbers and answer these plainly, with the people who'll build and support it in the room:
- How often does the same person come back? Weekly or more is app territory. A few times a year is web territory.
- Where are they when they use it? At a desk, on a couch, or on a ladder with one free hand?
- What must work without a signal? Name the actual task, not "everything."
- What would a notification say that they'd thank you for? If you can't write three, push isn't a reason.
- Who owns it in year two? Updates, store reviews, old versions, support.
If the answers point to an app, build one for the people who'll use it every week, and do it properly. We work through a real shift with those people before designing anything, which is the start of most of our mobile application projects. If the answers point to the web, a fast, focused mobile site is real product work too, and it's part of our web application practice.
Either way, tell us who your weekly users are, and we'll help you work out which front door they need.
Related work: WorkStep.
We build alongside the people doing the work.
Bring us the problem you’re thinking about.