When a PWA Beats a Native App for Your Startup's Budget

A founder decides they need a mobile app, and the next conversation is almost always the wrong one. It jumps straight to iOS and Android, to Swift and Kotlin, to two codebases and a team to maintain them, to App Store review queues and the thirty percent the stores take. That is a large, expensive commitment made before anyone has asked the only question that matters at the start: does this product actually need a native app yet, or does it need to be in front of users fast and cheap so you can find out whether anyone wants it at all.

The choice is not binary. There are three real options, PWA, cross-platform with React Native, and full native, and they sit on a spectrum of cost, reach, and capability. Picking the wrong end of that spectrum for your stage burns money and time you do not have. Picking the right one gets you to revenue faster and keeps your options open for when you genuinely need more.

What each option actually buys you

A progressive web app is a website built to behave like an app: installable to the home screen, capable of working offline, fast, and delivered through the browser. Making it feel native on iOS despite Safari's limits is the real engineering challenge, but a single PWA built with a modern framework serves desktop, Android, and iOS users simultaneously from one codebase. There is no app store, no review, no two-platform split.

React Native sits in the middle. It lets you write one codebase that compiles to real native apps for both iOS and Android, eliminating the old requirement of two separate native codebases. You get into the app stores and gain access to native capabilities, at a development cost well below building two fully native apps, while sharing most of your logic across platforms, and a pipeline that lets you ship React Native updates the same day you write them recovers much of the iteration speed a PWA gives you for free.

Full native means separate iOS and Android codebases, in each platform's own language, with maximum access to device capabilities and the best possible performance and platform integration. It is the most expensive and the most powerful, and it is the right answer for a specific class of product.

The economics that decide it for early startups

For a startup before product-market fit, the dominant factors are speed to market, cost, and how much of your revenue you keep, and on all three the PWA wins decisively.

• Time to market. PWAs ship faster because there is no app store approval to wait on and no second platform to build. You iterate daily, pushing updates that reach every user instantly rather than waiting on a review queue and a user's decision to update.
• Revenue retention. PWAs avoid the app store fee that takes up to thirty percent of revenue on in-app purchases, so you keep effectively all of what you earn. For an early company watching every dollar, handing thirty percent to a store before you have proven the model is a hard cost to justify, and you also dodge the app store rejections that quietly cost a shipping startup its launch date.
• Distribution friction. A PWA is acquired through the open web, which means SEO, social links, and a shared URL all funnel directly into your product with no install gate. A user clicks a link and is using your app, no store visit required.
• Conversion impact. PWAs have been reported to lift mobile conversion rates meaningfully and reduce bounce, in part because the friction of an install step is removed from the path to using the product.

This is why the prevailing pattern for startups has shifted toward PWA-first, native-later: build the MVP as a high-performance PWA, acquire users through the web with zero install friction, keep all your revenue, and iterate fast. Then, once traction is proven, rebuild native if and when the product genuinely needs it. This staging de-risks the spend. You do not commit to the expensive native build until you have evidence the product deserves it, which is the same discipline behind scoping an MVP that ships in six weeks rather than gold-plating before anyone has bought.

When native is actually the right call

PWA-first is the default, not a law. Native, whether cross-platform or full, is the correct choice when the product needs capabilities the web cannot reach or a level of integration the browser cannot match.

Native is best when you need complex device integrations, deep sensor access, background processing that the web restricts, or platform-level features like advanced push, hardware security elements, or tight OS integration. Banking apps, logistics with continuous sensor and location tracking, regulated health apps, anything where the native platform's capabilities or compliance posture are central to the product, these are native from the start because the web genuinely cannot do what they require. Where the product needs to keep working through patchy connectivity, you also have to design offline-first mobile sync that survives bad networks, which is its own engineering project on top of the platform choice.

There is also a discovery argument. Native apps benefit from app store discovery and the download behavior that comes with it, which matters for consumer products where being findable in the store is a real acquisition channel, and where push notifications people open instead of mute become a retention lever the web reaches less reliably. If your growth model depends on store discovery, that weighs toward native even when the web could technically deliver the features.

The honest framing is that the PWA-versus-native gap has narrowed considerably as PWAs matured and closed much of the performance and feature distance, while native still delivers the most power and the deepest platform integration. So the question is not "which is better" in the abstract. It is "which capabilities does this specific product actually require, and at this stage, can the cheaper, faster option deliver them."

A framework you can actually apply

Run your product through these questions in order.

First, does the product need device capabilities the web cannot reach, deep sensor access, background tasks, hardware integration, a specific compliance requirement? If yes, you are heading native, and the next question is whether React Native's shared codebase suffices or whether you need full native's maximum capability. If no, keep going.

Second, what is your stage? If you are pre-traction and trying to validate the market, a PWA gets you there fastest and cheapest, keeps all your revenue, and removes the install gate from your funnel. Validate first, build native later if the traction justifies it.

Third, does your growth depend on app store discovery? If store presence is a core acquisition channel for your audience, that pushes toward native even when the web could carry the features, because being in the store is part of the product's reach.

Most early products, B2B SaaS, content-heavy apps, and tools where the value is the software rather than deep device access, land on PWA-first. A meaningful minority, the ones built around device capabilities or store-driven consumer distribution, are native from day one. The mistake is not choosing native. The mistake is choosing native by default, before asking whether this product, at this moment, needs it.

The decision worth making slowly

This choice deserves more thought than it usually gets, because it sets your cost structure, your iteration speed, and how much of your revenue you keep for the next year or more. When we plan mobile apps with a client, the first work is not architecture, it is figuring out which of the three options the product actually needs at its current stage, so the build matches the moment rather than overbuilding for a future that may never arrive. Often that conversation belongs even earlier, in a consultation where we pressure-test whether the product needs an app at all or whether a fast PWA is the smarter first move toward revenue.

The teams that win here are not the ones with the most impressive native apps. They are the ones who shipped the cheapest thing that could prove the market, kept their revenue while they did it, and earned their way into the expensive native build with traction rather than guessing into it. Start with the question, not the platform, and the platform answers itself.