Most minimum viable products should launch as a web app, because it ships sooner, updates instantly and avoids app store review, fees and commission. Build mobile first only when the core value depends on something the web can't do reliably on a phone — dependable push notifications, background location, sustained camera or Bluetooth use, offline work in the field — or when your users will look for you in an app store. Shark Labs builds web-first MVPs on a backend that a React Native app can share later, so mobile is a second front end rather than a rewrite.
A founder who asks us for "an app" usually means one of two things: software their customers use on a phone, or an icon in the App Store. Those are different requirements, and only the second one strictly needs a native build. Sorting out which one you mean is the cheapest decision in the whole project, and getting it wrong is one of the most expensive.
The default, and the reason for it
An MVP exists to find out whether anyone wants the thing. Everything that slows the loop between shipping a change and seeing what users do with it makes the MVP worse at its one job. The web has the shortest loop there is: you deploy, and every user has the new version on their next page load.
A store app adds a step to that loop and several to the launch. None of them are hard. All of them take calendar time, and in the first three months calendar time is the scarcest thing you have.
What the app stores add to your calendar
| Step | Apple App Store | Google Play |
|---|---|---|
| Developer account | $99 a year | $25, one-time |
| Registering as a company | Needs a legal entity and a D-U-N-S number, which Dun & Bradstreet can take up to five business days to issue | Organisation account, which also asks for a D-U-N-S number |
| Before your first public release | App Review | New personal accounts: a closed test with at least 12 testers, opted in for 14 consecutive days |
| Review of each update | Apple says 90% of submissions are reviewed in under 24 hours, on average | Usually hours to a few days; no published target |
The row that catches people is Google's. Since November 2023, new personal developer accounts must run a closed test with twelve opted-in testers for fourteen continuous days before they can even apply for production access. That is two weeks you can't compress, and twelve people who have to actually install the build. It applies to personal accounts, which is one more reason to register the company properly from day one rather than publishing under a founder's own name.
Apple's per-update review is usually quick, but it is still a gate between you and your users. When a fix matters, a day in a queue matters. Over-the-air updates in Expo close most of that gap for JavaScript changes, though anything touching native code or permissions goes through review again.
What the app stores take from your revenue
If your product sells digital goods or subscriptions inside the app, both stores take a commission through their own payment systems: 30% as the standard rate, and 15% under Apple's Small Business Program for developers with up to $1 million in proceeds a year, with Google running an equivalent reduced tier.
Two qualifications matter more than the headline rate:
- Physical goods and real-world services are outside it. If customers are paying for a delivery, an appointment or a massage chair, you use your own payment provider and the store takes nothing. Many MVPs fall here and the commission question simply disappears.
- The rules on linking out to web checkout are still in court. In the US, Epic v. Apple has moved what apps may do several times since 2021, and the appeals court sent the question of what Apple may charge on linked purchases back for a new decision in December 2025. Don't build a business model on the current state of a live lawsuit. Plan for in-app purchase; treat cheaper web checkout as upside.
What a web app still can't do on an iPhone
Android is generous to web apps. iOS is where the web-first plan gets tested, so this is the list to check against your core loop. As of iOS in late 2026:
- Push notifications work, but only after the user installs the web app to the Home Screen. Web push arrived in iOS 16.4 in 2023. A site open in a Safari tab cannot receive them, and there is no automatic install prompt on iOS; the user has to find Share, then Add to Home Screen. Expect a small fraction of users to do that.
- The installed app starts signed out. Home Screen web apps keep their storage separately from Safari, so a user who signed in on the website signs in again in the installed version.
- No background sync or background fetch. A web app can't quietly upload a queue of offline work or refresh data overnight. If field staff need to capture data with no signal and have it sync later without opening the app, that is a native requirement.
- Narrower hardware access. No Web Bluetooth or NFC in Safari, and no continuous background location. A camera works fine for a photo upload, less well for anything sustained or real-time.
If none of those sit in the loop your product depends on, the web will carry your MVP. If one of them is the product, it won't, and no amount of clever engineering changes that.
When mobile really does have to come first
- Push is the product. A habit app, a delivery tracker, a marketplace where speed of reply decides the sale. If the notification is how value reaches the user, you need it to arrive reliably for everyone, not just the ones who installed a web app.
- The phone's hardware is the feature. Scanning, Bluetooth devices, background location, sustained camera use, heavy on-device processing.
- The work happens offline. Field teams, warehouses, site visits, anywhere the signal is poor and data has to queue.
- Users discover you in the store. Some consumer categories are searched for in the App Store rather than on Google. If that's your acquisition channel, the listing is the storefront.
- A buyer requires it. Some B2B customers' IT teams only allow managed mobile apps. That is a sales constraint, and a real one.
The path that keeps both options open
The choice is less permanent than it feels, provided the first build is structured for it. What makes mobile expensive later is a web app whose business logic lives in its pages. What makes it cheap is a backend that owns the logic, with the web app as one client of it.
- 01Version one: a responsive web app on Next.js, designed mobile-first, with the data, rules and permissions in Postgres behind an API — not in the front end.
- 02Measure which users come back on their phones, and whether anything in the iOS list above is costing you retention.
- 03Version two, if the evidence says so: a React Native app with Expo, as a second client of the same backend. Accounts, data and business rules carry over; you are building screens, not a second product.
This is how we scope MVPs on our app development service. It is also why "web and mobile" is one of the three things that moves an MVP quote, alongside user roles and payments: doing both at once means two sets of screens, device testing and store submission inside the same budget and timeline. Doing them in sequence means the second one is only paid for once you know you need it.
The quick test
| Question | Points to web | Points to mobile |
|---|---|---|
| How do users find you? | Search, links, ads, sales | App Store search |
| What do they pay for? | Physical goods, services, B2B | Digital content in the app |
| Does value arrive by notification? | Sometimes | Always |
| Does it need hardware or background access? | Camera upload at most | Yes |
| Do users work offline? | Rarely | Routinely |
| How fast must fixes reach users? | Same day | Review is acceptable |