The Question Behind The Question
When a business asks for an app, the underlying motivation is usually one of a few things: customers complain the site is awkward on a phone, a competitor has an app, someone wants to send push notifications, or an app feels like the more serious commitment.
Only one of those is an app problem. The others are, in order, a mobile website problem, a positioning anxiety, and a notification requirement that has other solutions. It is worth being honest about which one applies before committing to a build that will cost several times what the alternative would.
What Only A Native App Can Do
The genuine capabilities, stated plainly:
- Deep hardware and sensor access — sustained camera processing, Bluetooth peripherals, precise background location
- Reliable background execution — work that continues when the app is closed, such as fitness tracking or navigation
- Genuine offline-first operation with substantial local data
- Dependable push notifications, particularly on iOS without an installation step
- App store distribution, where customers expect to find you there
- Platform integrations — widgets, watch apps, in-car interfaces, share sheets
- Heavy on-device computation — real-time graphics, video editing, on-device models
If your requirement does not appear on that list, a website will almost certainly serve you better.
What A Modern Website Already Does
The gap has narrowed considerably, and many objections to web are several years out of date.
- Installable to the home screen with an icon, on both major platforms
- Works offline for previously visited content
- Push notifications on Android and desktop, and on iOS once installed
- Camera and microphone access for capture and scanning
- Location, with permission
- Native payment sheets — the same wallet flow customers use in apps
- Biometric authentication through passkeys
- Fast, fluid interfaces indistinguishable from native for most business use cases
Crucially, a website is findable. It appears in search results, opens from a shared link, and requires no installation decision. For any business whose customers discover them rather than already knowing them, this is decisive.
The Cost Comparison Nobody Runs
| Factor | Website / PWA | Native app |
|---|---|---|
| Codebases | One | Two, or one cross-platform with compromises |
| Distribution | A URL | Store submission, review, rejection risk |
| Updates | Instant, for everyone | Review cycle, and users who never update |
| Ongoing maintenance | Moderate | High — annual OS releases force work |
| Discovery | Search, links, sharing | Store search, or paid acquisition |
| Friction to first use | One tap | Find, download, register |
| Store fees | None | Developer accounts, plus commission on digital sales |
The row that surprises people is maintenance. An app is not a project that finishes. Operating systems update annually, devices change shape, and an app left untouched for two years will eventually break or be delisted. Budget for the app's second and third years before approving its first.
A Decision Sequence
- Does it need a capability only native provides? If yes, build native, and stop reading.
- How often will a customer use this? Daily or weekly supports an app. A few times a year does not.
- Is your mobile website genuinely good? Test it honestly. Most businesses considering an app have a mobile site with real, fixable problems, and building an app leaves those problems in place for everyone who never installs it.
- Do customers already know you? Apps work for existing relationships. Discovery happens on the web.
- Can you fund three years? If the budget covers a build and nothing after it, an app is the wrong commitment.
- Would a PWA satisfy the actual requirement? Test it first. It is cheaper to discover the answer than to assume it.
The Middle Path Most Businesses Should Take
Build an excellent mobile website, make it installable, and add notifications if they are needed. Then measure. If a substantial group of customers is using it weekly and hitting genuine limits of the web platform, you will have both evidence and an existing audience to launch a native app to — which is a far better position than launching one on a hypothesis.
This is also the sequence that protects you from the most common outcome: an app built at considerable expense, installed by a small fraction of customers, and quietly retired two years later while the mobile website that was never improved continues to serve everybody else. The trade-offs here mirror those in choosing a build approach more generally.
When The Answer Really Is An App
To be clear, some businesses should build one. Logistics operations with drivers working offline in poor coverage. Field service teams capturing data on site. Products with genuine daily habit. Anything requiring background location or sustained sensor access. Businesses whose customers expect to find them in a store as a matter of category convention.
If that is you, build it properly, resource it for the long term, and do not treat it as a marketing project. A neglected app damages a brand more than no app does, because it is visible, rated publicly, and broken in front of the people who liked you enough to install it.
What To Do First
- Open your site on a mid-range phone, on mobile data, and complete your main customer task
- Write down every point of friction you hit
- Ask whether an app would solve those, or whether fixing the site would
- Check how often a typical customer would realistically use the thing
- Price the app honestly, including three years of maintenance
- Test a progressive web app against the actual requirement before committing
- Decide with evidence rather than with competitor anxiety
We build both, and we regularly advise clients out of app projects they arrived asking for — usually because the mobile site was the real problem and cost a fraction to fix. If you are weighing this up, we will give you a straight answer about which one your situation calls for.