Ask ten founders whether they need a mobile app and nine will say yes before you finish the question. An app feels like the serious answer, the grown-up product, the thing on a phone screen. But native, web and progressive web app are not tiers of seriousness. They are different tools for different behaviours, and picking the wrong one is expensive in ways you only feel a year later. The decision is simpler than it looks once you start from the right place.
Start from how people actually use it
Before you compare technologies, watch the behaviour you are building for. Where is the person when they use this — at a desk, on a factory floor, in a car, in a queue? How often do they reach for it, and do they come back through a link, a home-screen icon, a bookmark, or a notification? Do they need it when there is no signal? Is there a search or a shared link that has to lead straight into it?
The answers point at the platform before you have named a single technology. A tool people open all day from their pocket, offline, wants to live on the home screen. A tool people reach through a colleague's link, on whatever device is in front of them, wants to be the web. Get this observation right and the rest of the decision mostly makes itself.
The reason to start here, rather than with a preference, is that behaviour is the one input that does not lie. A founder's instinct that the product should be an app is usually about how it will look to investors or competitors, not about how anyone will use it. Watch a real user for ten minutes and the platform argument that felt subjective becomes a matter of fact. You are not choosing what you would like to build; you are noticing what the usage already demands.
What native mobile is genuinely good at
A native app earns its cost when it needs the phone to be more than a screen. Real offline use, where the app works fully with no connection and syncs later. Deep access to the device — camera, precise location, Bluetooth, background activity, reliable push notifications that arrive even when the app is closed. And presence in the app stores, which for a consumer product is a genuine channel where people go looking for exactly this kind of thing.
Those strengths are real and sometimes decisive. But they arrive attached to costs that do not show up in the demo. You are building for two platforms with meaningfully different rules. Every release passes through a review process you do not control. And you cannot simply fix a bug and push it — the update has to be approved and then actually installed by users, some of whom never update at all. Native is powerful and heavy in equal measure.
That last point is worth sitting with, because it changes how you have to build. On the web, a mistake is embarrassing for an hour until you deploy the fix. In a native app, a mistake ships to phones and stays there until each user chooses to update, which means you are supporting old versions of your own software in the wild for months. Everything that follows — more careful releases, longer test cycles, backward compatibility you did not expect to owe — is a tax you pay precisely because the strengths are real.
What the web quietly wins
A web app asks nothing of the user but a link. Nothing to install, nothing to approve, instant reach on every device with a browser, and a fix you deploy once is live for everyone the next time they load the page. For anything that lives behind a login, that people use at a desk, that has to be shareable and searchable, the web is not the compromise — it is usually the right answer outright.
Its limits are the mirror image of native's strengths. Access to device hardware is narrower, offline support takes deliberate work and never quite matches native, and there is no app-store shelf to be discovered on. For a large class of business software none of that matters. The question is whether your product falls in that class, and most business tools do.
The web also carries an advantage that only shows up over time: it is the platform you never have to ask permission to change. There is no gatekeeper between a fix and the user, no review queue, no version of your software frozen on a device belonging to someone who declines to update. Everyone is always on the current version, because the current version is simply what loads. For a product that will evolve steadily — which is most of them — that single property quietly removes an entire category of friction that native teams live with forever.
PWA: the middle path and where it stops
A progressive web app is a web app that behaves more like an installed one. Users can add it to the home screen, it can work offline to a degree, it can send notifications on most platforms, and it does all this from a single codebase reachable by a plain link. For many products it is the honest sweet spot — most of the native feel without the two-codebase cost or the store gatekeeping.
It is not magic, and pretending otherwise leads to disappointment. A PWA cannot reach every device capability, its background behaviour and notifications are weaker and less consistent than native, and support has historically been uneven across platforms — one major mobile platform has treated PWAs as a second-class citizen for years. For a product whose whole value is deep device integration or flawless offline, a PWA will feel like it is straining. For a product that would love to be on the home screen but does not truly need the metal underneath, it is often exactly enough.
The useful way to think about a PWA is as the option you reach for when native's strengths would be nice but are not the point. If you find yourself justifying native mainly by the wish to have an icon on the home screen and to send the occasional notification, a PWA gives you both without the second codebase or the store review. Reserve native for when the honest answer to why not a PWA is a specific capability you can name and genuinely depend on — not a general feeling that native is more real.
The cost multiplier nobody quotes upfront
Here is the number that reframes the whole discussion. Going native for both major platforms means, in effect, building and maintaining the product more than once — two codebases, two release cycles, two sets of platform quirks, and a maintenance bill that keeps arriving for as long as the app lives. A web app or a PWA is one codebase serving everyone. Cross-platform frameworks narrow the gap but do not erase it; there is still real platform-specific work under the shared layer.
Before you commit to native, be sure the strengths you are paying double for are strengths your product actually uses. A great deal of native mobile development is a company paying the two-platform premium for capabilities it never touches, because an app felt more serious than a website. That premium is best spent on purpose, not on instinct.
The premium is also not a one-time payment. Two codebases cost more to build, but the heavier bill is the one that never stops: every new feature has to be built twice, every bug reproduced and fixed twice, every platform update absorbed twice, for as long as the product lives. A decision that adds a modest percentage to the initial quote can double the running cost of the software for years. That is the number to weigh, and it is the one most rarely put on the table before signing.
Discovery works differently on each platform
One factor tips more decisions than people expect: how your users will find you in the first place. A native app lives in an app store, where people actively browse and search for tools of a certain kind, and for a consumer product that store presence is a genuine channel worth having. But it is a channel with a gatekeeper, a ranking system you do not control, and a queue between you and every update.
The web is discovered differently. People arrive through a search engine, a shared link, a post, an email — anywhere a URL can travel. For business software, an internal tool, or anything sold through relationships rather than browsing, that reach is usually far more valuable than a shelf in a store, and it costs nothing to be linkable. Before you decide native for the sake of the store, ask honestly whether your users go looking in app stores for something like yours, or whether they will only ever arrive by link. The honest answer often settles the platform on its own.
A framework, and permission to start small
Put it together into one line of reasoning. If your product genuinely needs deep offline, heavy device access or an app-store presence, build native and budget for two platforms honestly. If it needs reach, shareability and fast iteration and lives mostly behind a login or on a desk, build web. If it wants the home screen and light offline but not the metal underneath, a PWA is likely your best value. When two of these feel close, the cheaper, single-codebase option wins the tie.
And you do not have to decide forever on day one. A perfectly good path is to launch on the web or as a PWA, learn how people actually use it, and add a native app later if and when the behaviour proves it is worth the second codebase. Starting small is not a lack of ambition — it is refusing to pay the biggest bill before you have evidence you need to. If you want help matching the platform to how your users actually behave, start with a call.