An app in the stores carries overhead a website never pays: two platforms to keep compatible, Apple and Google review on every release, users who must find, download, and update it, and store policies that can change under you. That overhead is fine — when you're getting something for it. The mistake is paying it by default.
Start from the default: the web
A well-built web application works on every phone, laptop, and tablet your users own, updates instantly for everyone, and has no gatekeeper between you and shipping. For products people use occasionally — checking an account, booking a service, filling a form — install friction actively costs you users: every "download our app" interstitial loses people who just wanted the thing done.
So the honest starting position is: it's a web app until proven otherwise. The proof comes from needing things only a native app can do well.
When an app earns its overhead
- Push notifications drive the product. If the workflow is "we alert you, you act" — dispatch, approvals, alerts — native push is dramatically more reliable than the web's version.
- Offline is non-negotiable. Field crews in basements and rural routes need the app to work with zero signal and sync later. This is native territory.
- Hardware is core. Heavy camera use, barcode scanning, GPS tracking, sensors — browsers can touch these, but apps own them.
- It's a daily habit. If your users open the product every day, the home-screen icon and instant launch are worth real money.
- The store is your channel. For some consumer products, being found in the App Store is itself the distribution strategy.
One genuine need from this list can justify an app. Zero means you're about to pay double to ship slower.
The middle path most people miss
This isn't a one-time, all-or-nothing decision. The pattern we recommend most often: build the web application first, on a clean API. Launch, learn, and earn revenue with it. If usage data later shows a real case for native — people asking for notifications, field staff fighting spotty coverage — add a focused mobile app on the same API, covering just the mobile-critical workflows.
Built this way, the app is a fraction of the original scope, because the accounts, business logic, and admin tools already exist. You paid the store overhead only once you knew it would pay you back.
A decision shortcut
Three questions get you most of the way:
- Would your users open this more days than not? If no — lean web.
- Does it need to work with no signal, or wake users up with notifications? If yes — lean app.
- Are you still guessing about what users want? If yes — build the web version first and stop guessing.
And one heuristic from the trenches: if the phrase "we need an app" came from a marketing conversation, it's usually a web app. If it came from people doing the work in the field, it's usually real.