"Should we build a mobile app or a website?" is one of the most common questions we get in discovery, and the answer is genuinely "it depends".
Four questions decide it.
1. Where does your user already live?
If your user is on their phone — commuting, on a worksite, between meetings — the friction of opening a browser and typing a URL is real. They'll engage with an app icon they can tap once. They won't engage with a URL they have to remember.
If your user is at a desk for most of their use case — running reports, managing accounts, doing knowledge work — a web app is faster to access, faster to update, and easier to share.
The naive answer "mobile-first, always" is wrong for a large portion of B2B products.
2. Do you need offline?
If your users are in environments with patchy connectivity — fieldwork, mining sites, hospitals, regional Australia generally — a native app with proper offline-first sync is dramatically better than even the best progressive web app. Service workers can do a lot, but full offline behaviour with conflict resolution still needs native investment.
If your users always have a connection, a web app is usually fine.
3. Do you need hardware features?
Camera with native quality controls, biometric authentication, NFC, Bluetooth, accelerometer-based gesture detection, push notifications that arrive within seconds rather than minutes — these are all better (sometimes only) available in native apps.
Web has caught up on a lot (camera capture, basic notifications, biometric WebAuthn) but the polish gap is still real for hardware-heavy products.
4. What's your release cadence?
A web app is a deployment. A native app is a deployment plus an app store review.
If you're shipping changes daily and want the option of rolling back instantly, that's a web app's natural shape. If you're shipping every few weeks and care about polish more than speed, the app store cadence is less painful.
A reasonable default
For a B2C consumer product where users discover you and then want to deepen engagement: web first, native app later when retention proves the audience.
For a B2B internal-ops tool where users live in the product daily: web app, almost always.
For field workforce, regional services, or anything offline-heavy: native, almost always.
For something that needs both a polished consumer experience and a power-user back-office: web app for the back-office, native for the consumer, sharing a backend.
Progressive web apps as the middle path
PWAs (progressive web apps) close more of the gap every year. iOS support is now reasonable, Android support has been good for ages. For many B2C use cases that previously demanded a native build, a PWA today is a respectable choice.
The places PWAs still fall short:
- Push notifications on iOS (improved but not at parity)
- Background processing (limited)
- App store discovery (PWAs are getting better but native apps still win)
- Native polish on transitions, haptics, keyboard handling
If you'd genuinely be embarrassed by a PWA's UX, build native. Otherwise, a PWA is a serious option that saves 40–60% versus dual native.
The version of this we recommend most often
Build the smallest credible version on whichever platform best matches your users. Ship it. Use real usage data to decide whether the next investment is a second platform, deeper features, or a different product entirely.
The expensive mistake is committing to the full both-platforms build before you know whether the product idea works.
If you'd like a senior team's view on your specific situation, book a discovery call.
