Somebody has told you that you need an app rather than a website. Possibly a competitor launched one, possibly a customer asked, possibly it was an agency, and if it was an agency it is worth knowing that the app is the bigger project by a wide margin.
For most small and medium businesses the honest answer is no, or not yet, and there is a middle option that almost nobody offers you. The good news is that this is genuinely decidable. It is not a matter of ambition or taste, it comes down to five questions about what your customers actually do, and you can answer them in about ten minutes.
Do you need an app or a website? The five-question test
Answer honestly rather than aspirationally. The right answer describes your customers as they are today.
- How often does the same person come back? Weekly or more is app territory. Monthly is arguable. A few times a year is not, because nobody keeps an app they open twice a year, and they will not install it in the first place.
- Does anything need to work with no signal? Genuinely, not theoretically. Engineers in plant rooms, drivers in rural areas, anyone in a basement or a warehouse. If yes, that is the strongest single argument for an app there is.
- Do you need to reach people when they are not thinking about you? Notifications are the real superpower, and the thing a website cannot fully match. But be honest about whether you have something worth interrupting someone for, because the alternative is being muted or deleted.
- Do you need the device itself? Camera and scanning, precise or background location, biometric sign-in, wallet passes, Bluetooth to a physical device. Some of this a browser can now do, some it cannot.
- Does it belong on the home screen? Not a technical question, a habit one. Is your business something a person would want a permanent icon for, or something they look up when they need it? Most businesses are the second kind, and there is no shame in it.
What a website can do now that it could not five years ago
This is where most of the outdated advice comes from. People carry a mental model of websites from a decade ago, and it is wrong in ways that matter to this decision.
- Install to the home screen, with your icon, opening without browser chrome. It looks and feels like an app to a normal person.
- Work offline, at least for what has already been loaded. Not as completely as a native app, but far better than nothing.
- Send notifications, on both major platforms now, which for years was the one unanswerable argument for going native.
- Use the camera, including scanning codes, which covers a large share of what people wanted the camera for.
- Take payments with the same saved-card flows people already use, without a store taking a cut.
- Update instantly, with no review queue and no waiting for customers to update anything.
What a website still cannot match: background location, deep integration with the operating system, the very smoothest animation, and being found by browsing an app store. That last one matters less than people expect, because almost nobody discovers a small business by browsing a store.
The middle option: your site as an app
Between a website and a ground-up native app there is a third thing, and it is the right answer surprisingly often. You take the site you already have, add the native capabilities you actually need, and publish it to the stores as a real installable app.
The important caveat, and the reason to be careful who builds it: a shell around a website with nothing added will be rejected, and rightly so. The value has to be real. Notifications people will accept, useful offline behaviour, camera or scanning, biometric sign-in, wallet passes, proper deep links. Add those and it is a legitimate app. Skip them and you have bought a rejection, which is exactly what app rejected by Apple is about.
| Website | Site as an app | Native app | |
|---|---|---|---|
| Illustrative build cost | $8,000 to $30,000 | $12,000 to $40,000 on top of a decent site | $40,000 to $150,000 and up |
| In the app stores | No | Yes, both | Yes, both |
| Notifications | Yes | Yes, and more reliably | Yes, fully |
| Works offline | Partly | Mostly | Fully |
| Camera and scanning | Yes, basic | Yes | Yes, everything |
| Background location | No | Limited | Yes |
| Updates | Instant | Instant for content, review for the shell | Every change waits for review |
| Ongoing cost | Hosting | Hosting plus developer accounts | Hosting, accounts, and two codebases to maintain |
Illustrative ranges from the kind of work we quote, not a price list. The gap that surprises people is the last row: a native app is two things to keep working forever, and that cost never stops.
When a real native app is worth it
So that this is not one-sided, the cases where we would tell you to build the proper thing:
- Daily use by the same people. Field teams, drivers, dispatch, anything that is somebody's working tool rather than an occasional errand.
- Real offline requirements, where the work happens where the signal does not.
- Heavy device use: continuous scanning, background tracking, Bluetooth hardware, anything sustained.
- The app is the product, and you are charging for it or it is the thing customers are buying.
- Performance that has to be flawless, which in practice means games and a small number of graphics-heavy tools.
If you are in one of those, build it properly and budget for both platforms indefinitely. Our customer apps work is that case, and what a mobile app costs has the detail on where the money goes.
The obligations nobody mentions in the pitch
Whichever of the two store routes you take, publishing an app is not a one-off act. It is an ongoing relationship with two companies who change their rules, and this is the part that is missing from almost every proposal.
- Developer accounts, annually. Both platforms charge a yearly fee to keep your app listed, one modest and one very modest. Small money, but it lapses quietly and your app disappears with it.
- Every change waits for review, and approval is a reviewer's judgement rather than a checklist you can pass. Nobody can promise you an approval date, and anyone who does is guessing. Budget for at least one rejection round on a first submission.
- Platforms deprecate things. Roughly annually, each will require a newer build target, a new privacy declaration or a change to something you were relying on. Ignore it for long enough and the app stops being downloadable.
- Two of everything, forever, if you go fully native. Two codebases, two release processes, two sets of device quirks. This is the cost that surprises people most, because it appears after the project is finished and nobody budgeted for it.
- A store takes a cut of anything you sell as a digital good inside the app. If your business model involves selling access, work out that arithmetic before anything is built rather than after.
None of that is a reason not to build an app. It is a reason to know what you are signing up for, and it is why the middle option is attractive: you carry the store obligations for one shell rather than for two full applications, and most of your changes ship as web content without waiting for anyone's review.
An app will not help you be found on Google. App content is not indexed the way web pages are, and launching one does nothing for your search visibility. If being found is the actual goal, the money belongs in your website and in what you publish on it, every time. Apps are for people who already know you and come back. Websites are for everyone else, which is most people.
Not for you if
Ten minutes with those five questions will settle it more reliably than a month of discussion, because the discussion tends to be about what a business would like to be, and the questions are about what customers actually do.