PWA vs Native App for Your MVP: How to Choose
"We need an app."
I hear this constantly, and nine times out of ten the founder means "we need our thing to work well on a phone." That is not the same as "we need a native app in the App Store," and confusing the two can cost you months and tens of thousands of pounds you didn't need to spend.
So let's clear it up. There are broadly two ways to put your product on someone's phone, and picking the right one for your MVP is one of the highest-leverage early decisions you'll make.
The two options, in plain English
Progressive Web App (PWA)
A PWA is a website built to behave like an app. Users open it in a browser, and it can be "installed" to their home screen with an icon, run full-screen with no browser bar, work offline, and send push notifications. There's no App Store, no download, no approval process. You send someone a link and they're using it.
Native app
A native app is what you traditionally think of: downloaded from Apple's App Store or Google Play, built specifically for the phone's operating system. It gets the deepest access to the device and the most polished performance, at the cost of more work, more money, and the app stores standing between you and your users. (In practice, "native" for most MVPs means a cross-platform framework like React Native, which builds a real app for both iOS and Android from one codebase.)
The trade-offs that actually matter
Forget the technical purism. Here's what matters to you as a founder.
| PWA | Native | |
|---|---|---|
| Time & cost to launch | Lower: one codebase, ships like a website | Higher: more work, two stores to satisfy |
| App Store friction | None; you just share a link | Real: reviews, approvals, download step |
| Updates | Instant; you push, everyone has it | Users must update; Apple/Google review changes |
| Discovery | Via web, search, links | App Store search + browsing |
| Device features | Most of them now: camera, location, notifications, offline | All of them, deepest access |
| Performance | Excellent for most apps | Best for graphics-heavy or hardware-intensive apps |
| The 30% cut | You keep it | Apple/Google take up to 30% of in-app purchases |
When a PWA is the right call
For a lot of MVPs, probably most, a PWA is the smart choice. Go PWA when:
- You want to test the market fast and cheap. One codebase, no store approval, launch this month.
- The download step is a conversion killer. Every tap between "interested" and "using it" loses people. Making someone visit an app store, search, download, and open before they've seen any value is brutal for a young product. A link is frictionless.
- You need to iterate quickly. With a PWA you fix a bug or ship a feature and everyone has it instantly. No waiting on Apple's review queue.
- Your product is fundamentally content, forms, dashboards, or transactions. The vast majority of business apps are exactly this, and PWAs handle them beautifully.
A real example: ChargedUp
This is exactly the logic behind the ChargedUp QR order-at-table product. A customer sits down, scans a QR code on the table, and orders. Imagine if that flow required them to download an app first. Half of them would give up before they'd ordered a drink. Shipping it as a web app meant scan, order, done. Zero friction, no app-store gatekeeper, instant updates across every venue. For that product, a native app would have actively hurt the business.
When native is genuinely worth it
Native isn't dead. For the right product it's clearly the right answer. Build native when:
- You need deep or high-performance device features. Heavy 3D/graphics, real-time audio/video processing, advanced camera work, background location tracking, Bluetooth hardware, HealthKit-style integrations. PWAs have closed a lot of this gap, but the frontier still belongs to native.
- Reliable, rich push notifications are core to the product. PWA push has improved a lot, but if notifications are the heartbeat of your product, native is still more dependable, especially on iOS.
- App Store presence is part of the trust or distribution story. For some consumer products, "download us from the App Store" carries credibility, and store discovery is a real acquisition channel.
- You're building something people use daily, for a long time. The extra polish and performance of native pays off when an app is a long-term habit rather than an occasional errand.
I've shipped real native apps too, production React Native apps for the likes of Reach plc and ChargedUp, so this isn't a case of preferring whatever's easiest. It's about matching the tool to the product.
The decision, boiled down
Ask yourself three questions:
- Does the download step hurt me? If getting users into an app store would kill conversion, lean PWA.
- Do I need deep device features or top-tier performance? If yes, lean native. If you're not sure, you almost certainly don't, at least not yet.
- How fast do I need to learn? Earlier and faster favours a PWA, because you'll ship and iterate quicker and cheaper.
For most MVPs, my honest advice is: start with a PWA, prove the product, and go native later if and when you have a concrete reason. You'll launch sooner, spend less, learn faster, and keep the option open. Building native first "because that's what a real app is" is one of the most common and expensive early mistakes I see.
There's a broader version of this decision, build vs buy and where to spend a tight budget, that I cover in How Much Should a Custom App Cost.
Not sure which way to go?
This is exactly the kind of decision I help founders get right before a penny is spent building. Tell me what your product does and who uses it, and I'll tell you honestly which approach fits, and roughly what each would cost.
Let's find the right approach →
You can also read more about how I approach custom application development.
About the Author James Levine is a senior full-stack developer and fractional CTO based in Surrey. Ex-Amazon and Ticketmaster, he's shipped both PWAs and production native apps, and helps founders choose the right one instead of the expensive one.