"We need an app" is one of the most expensive sentences a business owner can say without thinking it through. The PWA vs native app decision routinely swings a project budget by a factor of three to five, and in my experience most businesses asking for a native app do not actually need one. They need a fast, installable mobile web experience, and they need it for a fraction of the cost.
I have built both. Native apps for products that genuinely required them, and progressive web apps for businesses that were about to burn 400 million rupiah on an App Store presence nobody would download. This article is the conversation I have with clients before any code gets written.
Let me give you the honest framework, including the cases where native truly earns its price tag.
What a PWA Actually Is
A progressive web app is a website built to behave like an app. It loads fast, works on any device with a browser, can be added to the home screen with its own icon, can cache content for flaky connections, and on Android can even send push notifications. There is no app store, no download barrier, no 30-day review queue. A user taps a link and they are in.
The technology is mature in 2022. Twitter, Starbucks, and Tokopedia all run serious PWA experiences. This is not an experimental shortcut; it is how a large share of mobile commerce already happens.
The critical business property: one codebase serves everyone. Your Android user, your iPhone user, and your customer on a laptop all get the same product. You maintain one thing.
The Real Cost Comparison
Numbers first, because this is where the decision actually lives. Plausible ranges for a mid-complexity product built by a competent Indonesian team in 2022:
| Item | PWA | Native (iOS + Android) |
|---|---|---|
| Initial build | Rp 80 to 200 juta | Rp 300 to 700 juta |
| Codebases to maintain | 1 | 2 (or 1 with Flutter/React Native, still heavier) |
| Yearly maintenance | 15 to 20% of build | 20 to 30% of build, times two platforms |
| Release cycle | Deploy anytime, instant | App store review, days per release |
| Update adoption | Immediate for all users | Users on old versions for months |
| Distribution | Share a link | Convince user to install |
That last row matters more than most owners realize. Getting a customer to install an app is a real conversion barrier. Industry data consistently shows most users install zero new apps in a typical month. Your marketing spend has to fight that inertia. A PWA link in a WhatsApp message has no such barrier.
Cross-platform frameworks like Flutter narrow the native cost gap, and I use Flutter where native is justified. But they do not eliminate app store friction, review delays, or the install barrier. The distribution problem is the expensive part, not just the code.
Where PWAs Cover the Use Case Completely
For the following, a PWA is not a compromise. It is the correct engineering answer:
- Catalogs, ordering, and booking. Restaurant menus, salon bookings, B2B order forms, course enrollment. Users arrive via link or QR code, transact, and leave.
- Customer portals. Checking order status, invoices, points, delivery tracking.
- Content and community. News, learning materials, member areas.
- Internal tools with office connectivity. Dashboards, approval flows, simple reporting.
A retail chain in Tangerang I advised wanted a native loyalty app quoted at Rp 450 juta. Their actual requirement: members check points and redeem vouchers at the cashier. We built a PWA for under Rp 120 juta, distributed it through a QR code at checkout and a WhatsApp link, and adoption beat their projections because there was nothing to install. The pwa vs native app question, asked honestly, saved them two thirds of the budget.
Speed matters here too. Whatever you build, if it loads slowly on a mid-range Android phone over 4G, it fails. I covered this in your website speed is quietly costing you sales, and everything there applies double to PWAs.
Where Native Genuinely Earns Its Price
I am not anti-native. I am anti-default-native. These are the cases where I tell clients to spend the money:
- Offline-heavy field work. Sales teams, surveyors, or technicians working in areas with no signal, syncing large datasets when connectivity returns. PWAs can cache, but robust offline-first data sync with conflict handling is native territory.
- Deep device hardware. Continuous background GPS tracking, Bluetooth device pairing, advanced camera pipelines, NFC. Browser APIs cover some of this partially, but production reliability across devices demands native.
- Daily-habit products. If your product's entire model depends on being opened every day, home screen presence plus reliable push notifications on both platforms matters. And here is the 2022 reality check: iOS Safari does not support web push notifications. If push to iPhone users is core to your business, that alone can justify native.
- Heavy real-time performance. Games, video editing, complex animations at 60fps on cheap devices.
If your requirement list does not include at least one of these, you are probably buying a native app for status, not function. "Competitors have one" is not a requirement.
The Sequencing Play: PWA First, Native If Earned
The smartest pattern I have seen is not choosing one forever. It is sequencing:
- Ship a PWA in 2 to 3 months.
- Measure real usage: return frequency, session depth, feature demand.
- If the data shows a daily-habit product or hard device needs emerging, build native then, informed by real behavior instead of guesses.
This is MVP thinking applied to the mobile decision. The businesses that regret their app spend are almost always the ones that built native first on assumptions. The PWA-first path converts a 500 million rupiah gamble into a 120 million rupiah experiment with a clear upgrade trigger.
The Takeaway
The pwa vs native app choice is a budget decision disguised as a technical one. Default to PWA. Pay for native only when offline-first field work, deep hardware access, or a daily-habit product with iOS push requirements is genuinely on your list, and be suspicious of anyone who quotes you a native build without asking which of those you have. The right vendor interrogates your requirements before writing a proposal. If you want a second opinion before signing one, that is a conversation I have often.