Mobile app or PWA: which to build first

Somewhere early in every product, a founder asks the same question: do we need an app in the App Store, or can we get away with a website? The honest answer annoys people who want a one-word reply. It depends on who your users are, what your product has to touch on their phone, and how much runway you are willing to spend before you have proof anyone wants the thing.

This is a walkthrough of the real decision. What a progressive web app can and cannot do in 2026, where a native build earns its keep, and a clear recommendation so you are not stuck in analysis for another month.

Frame the real decision

First, untangle two things that get blurred together. "Native app" usually means a build that ships through the Apple App Store and Google Play, installs from there, and can reach deep into the phone's hardware. A "PWA," a progressive web app, is a website built to behave like an app: it loads in the browser, but it can be installed to the home screen, run full screen without browser chrome, work offline, and receive push notifications.

The decision is rarely "app forever" versus "website forever." It is "what do we build for the first release," because the first release exists to learn whether the product is worth more investment. The real questions are narrower:

• Do you genuinely need to be in an app store for distribution or credibility?
• Does your product need device capabilities a browser cannot reach?
• What is your budget, and how many platforms are you signing up to maintain?
• Where does your audience already spend time, and how do they expect to find you?

Answer those four and the choice mostly makes itself.

An honest comparison

Let us be even-handed here, because both options are genuinely good at different jobs.

What a native app does better

A native app has full, reliable access to the phone. Background location, Bluetooth and NFC, the secure enclave for biometric login, advanced camera control, HealthKit and motion sensors, deep widgets and lock-screen integrations. If your product is a fitness tracker, a navigation tool, or anything that runs while the screen is off, you want native.

App stores also bring distribution and trust. Some users will not believe you are real until they can find you on the App Store, and certain audiences search the store the way they used to type URLs. Push notifications on native are more capable and more dependable. And for a subset of products, the store is the payment rail: if you sell digital goods to consumers, Apple and Google often require their in-app purchase system, a 15 to 30 percent cut but also a frictionless checkout users already trust.

The cost is real. You are usually maintaining two codebases (or one cross-platform codebase plus the platform-specific edge cases), shipping through review queues that can hold a fix for days, and paying the ongoing tax of OS updates that break things every autumn. None of that is fatal. It is just a bill that arrives every month, not once.

What a PWA does better than people think

The 2026 picture for PWAs is better than the reputation suggests, and worse than the cheerleaders claim.

A PWA can install to the home screen, run full screen, work offline through a service worker, cache aggressively for instant loads, and access the camera, microphone, geolocation, files, and clipboard. Web Push now works on iOS for installed PWAs, which closed the single biggest gap of the last few years. For most software, a dashboard, a B2B tool, a marketplace, a content product, a booking flow, a PWA does everything the product needs and ships from one codebase you have to build for the web anyway.

The honest limits still exist on iOS in particular. Background sync and background location are constrained. Bluetooth and NFC web APIs are unreliable or absent on Safari. There is no App Store listing, so store-based discovery and reviews are off the table. And iOS install is a clumsy "add to home screen" gesture rather than a one-tap store button, so you have to teach users to do it. If any of those matter to your product, weigh them honestly rather than waving them away.

Cross-platform native, the middle road

There is a third option worth naming: a cross-platform framework that compiles to real native apps from one codebase. It gets you into the stores and reaches most device APIs without writing everything twice. It is a strong choice when you truly need the store and the hardware but not two separate teams. It is still slower and pricier than a web build, because you are still in store review, still chasing OS updates, and still shipping binaries.

The recommendation

For most early products, build a fast web app or PWA first.

Not because native is bad, but because the first release exists to answer one question (does anyone want this?) and a PWA answers it faster and cheaper. One codebase, instant updates with no review queue, a link you can put in an email or an ad that opens the product in one tap, and a path to "installed" for the users who love it. You learn what people actually use, then you have earned the right to spend native money on the parts that deserve it.

Go native first only when one of these is clearly true: you need device capabilities the browser cannot reach, your audience discovers products in the app store and nowhere else, or you are selling digital goods to consumers and the store is your payment rail. If you are nodding hard at one of those, native is the requirement. If you are not sure, that uncertainty is itself the answer: start on the web.

This is the same restraint we bring to any MVP development engagement. Ship the smallest honest version, learn from real usage, and add cost where the product has proven it needs cost.

What to build first

Whichever way you lean, the foundation is the same, and that is the quiet argument for starting on the web. A good PWA and the web half of a native app are the same engineering: a fast front end, a clean API, and a backend that does not fall over.

Build it as a proper web app with a modern framework, our usual reach is Next.js and React, add a service worker for offline and installability, wire up Web Push, and make it feel instant on a mid-range phone on a bad connection. That last part matters more than the install prompt. A web app that loads in under a second and responds like a native one converts the skeptic better than a store badge does.

Crucially, this work is not thrown away if you go native later. The API you build serves a native client just as well as a browser. The design system, the auth, the data model, and the business logic all carry forward. You are sequencing the spend so the expensive platform comes after the cheap one has proven the idea.

The takeaway

Most early products should start with a fast web app or PWA, then go native for the reasons that justify it: hardware access, store-driven discovery, or in-app purchases. Decide on those four questions, not on which option sounds more impressive in a pitch deck.

If you want a straight answer for your specific product, the device APIs it needs, the audience it has to reach, and the budget it has to respect, that is the kind of call we are happy to have. Tell us what you are building and we will tell you honestly which one to build first, then build it.