Most companies default to "build an app" before asking whether they need one. A PWA is often the cheaper, faster answer - and sometimes it isn't. Here's how to decide before you spend the budget.
Reviewed by:Dezső Mező· Founder · Engineer, DField Solutions· 14 May 2026
"We need a mobile app" is one of the most expensive sentences a company can say without examining it. It commits you to a separate codebase, two app-store accounts, a review process, and an ongoing maintenance stream - before anyone has asked whether a progressive web app would have done the same job for a fraction of the budget. Sometimes a native app is exactly right. Often it isn't. This guide is the decision you should make before the framework decision: app, or PWA?
A progressive web app is a website built so it behaves like an installed app. The user adds it to their home screen; it opens full-screen with its own icon, no browser chrome; a service worker caches it so it loads instantly and works offline; and it can send push notifications. That last point is where most outdated advice goes wrong - web push has worked for installed PWAs on iOS since iOS 16.4, not just on Android. A modern PWA is much closer to a native app than the 2019 version was.
The decisive advantages are cost and reach. A PWA is one codebase - frequently the same codebase as your website - so you build and maintain one thing, not three. There is no app-store account, no submission, no review wait, and no 15-30% store commission on anything you sell. And it's a URL: you can link to it, a search engine can index it, and an update is live the moment you deploy, with nothing to approve.
A PWA is not a native app, and the gap, though narrower every year, is real. A native app is worth its higher cost when the product genuinely needs one of these:
A PWA shares its codebase with your web product, so the marginal cost of the "app" is small - service worker, install prompt, offline strategy, push. A native app, even built cross-platform with React Native or Flutter, is a separate product: its own build, its own release pipeline, store accounts and fees, a review cycle on every update, and a permanent maintenance stream because every iOS and Android version can break something. That maintenance stream is the cost most teams forget to price - a native app is never "done."
If budget is tight and the timeline is short, a PWA almost always wins on speed-to-market - there is no review queue between you and your users. You can ship, learn, and iterate the same day.
This is the fork that decides more cases than capability does. A PWA is distributed the way a website is: a link, a QR code, an entry in search results, a row in your email. You own the channel and the relationship. A native app is distributed through the App Store and Google Play: you get their discovery surface and their trust halo, but you also get their review process, their policies, their commission, and their power to delay or reject an update. Ask honestly: will your users find this by browsing an app store, or will you bring them to it yourself? If it's the latter, the store is overhead, not a channel.
Work down this list. If you answer "yes" to one of the native questions and mean it, a native app is probably justified. If not, a PWA likely does the job for less.
It is rarely a permanent either/or. A sound, low-risk path for many products: ship a PWA first. It's the fastest way to get a real product in front of real users, it costs the least, and it tells you whether the demand is there. If usage proves out and a concrete native-only need appears - store discovery matters more than expected, or a feature genuinely requires deep device access - you build the native app then, with real usage data to scope it. You spent the native budget on a validated product instead of a guess.
We build both, so the recommendation isn't pre-decided by what we'd rather sell. On a scoping call we work through the checklist above with you: if a PWA covers the need, we'll say so and save you the native budget; if the product genuinely needs a native app, we build it cross-platform with React Native or Flutter and handle the store submission end to end. Either way you own the code, and either way the decision is made on your product's needs, not our preference.
If you're weighing a mobile build, the mobile service page covers how we work, and a 30-minute discovery call is the fastest way to run the app-vs-PWA decision against your actual product. The glossary has a plain-language entry on PWAs and the related terms.
Founder, DField Solutions
I've shipped production products from fintech to creator-tooling · for startups and enterprises, from Budapest to San Francisco.
Let's talk about your project. 30 minutes, no strings.