“I need an app.”
That’s what most founders say in their first discovery call. And almost always, they mean a native iOS and Android app — the kind you download from the App Store.
Here’s the problem: building native mobile apps for an MVP is almost always the wrong move. It costs 2-3x more, takes twice as long, and locks you into two separate codebases before you’ve proven anyone wants what you’re building.
I’ve scoped over 40 MVP projects. Roughly 80% of them launched as web apps — and the founders who fought hardest for native mobile were usually the ones who’d never shipped a product before.
This isn’t about what’s “better.” It’s about what’s right for your stage.
What “Web App” and “Mobile App” Actually Mean
Let’s clear up the terminology, because most founders mix these up.
Static website: Brochure pages. No user accounts, no dynamic data. Think a landing page or portfolio site. Cost: $1K-$3K.
Web application: A full software product that runs in the browser. Users log in, interact with data, complete workflows. Think Notion, Figma, or Trello — all web apps. Cost for MVP: $4K-$8K.
Progressive Web App (PWA): A web app that can be “installed” on a phone’s home screen. It looks and feels like a native app but runs in the browser engine. Supports push notifications (on Android, limited on iOS), offline caching, and full-screen mode. Cost: same as a web app, plus 1-2 days of PWA configuration.
Native mobile app: Built specifically for iOS (Swift/SwiftUI) or Android (Kotlin). Distributed through app stores. Full access to device hardware — camera, GPS, Bluetooth, accelerometer. Cost for MVP: $15K-$25K for one platform, $25K-$40K for both.
Cross-platform mobile: Built with React Native or Flutter. One codebase, runs on both iOS and Android. Cheaper than two native apps but still requires app store distribution. Cost for MVP: $10K-$18K.
The 80/20 Rule: Start Web, Go Native Later
Here’s the math that changes most founders’ minds:
| Factor | Web App | Native (iOS + Android) |
|---|---|---|
| MVP build cost | $4,000-$8,000 | $25,000-$40,000 |
| Time to launch | 2-4 weeks | 8-16 weeks |
| App store approval | None | 1-4 weeks (Apple review) |
| Update deployment | Instant | Requires store re-submission |
| User acquisition | Share a URL | Convince users to download |
| Maintenance cost/year | $1K-$3K | $5K-$15K |
A web app lets you validate demand at one-fifth the cost. If your MVP proves product-market fit, you can always build native later — with real user data guiding what features actually need native hardware access.
The “web-first, native-later” strategy isn’t a compromise. Companies like Instagram, Twitter, and Product Hunt all started as web apps. Airbnb ran as a web-only product for years before investing in native mobile.
When You Genuinely Need Native Mobile
There are five scenarios where starting native makes sense. If none of these apply to you, start with a web app.
1. Camera-heavy workflows. If your product’s core feature requires real-time camera access — barcode scanning, AR overlays, document scanning with OCR — web browser camera APIs are too limited. Native gives you full control over the camera pipeline.
2. Offline-first requirements. If your users work in places with unreliable internet — field service workers, delivery drivers, rural healthcare workers — and need to capture data offline and sync later, native handles this more reliably than PWAs.
3. Bluetooth or hardware integration. Connecting to IoT devices, medical sensors, or payment terminals requires native Bluetooth APIs. Web Bluetooth exists but has poor cross-browser support and limited device pairing capabilities.
4. Intensive background processing. If your app needs to track GPS continuously in the background (fitness tracking, delivery routing), process audio in real-time, or run complex computations, native gives you the performance headroom browsers restrict.
5. Your market expects it. Consumer social apps, mobile games, and health/fitness products have user bases that overwhelmingly expect App Store presence. If your direct competitors are all native apps, a web app may create adoption friction.
Notice what’s NOT on this list: push notifications (PWAs handle those on Android, and iOS support is improving), user accounts and dashboards (web handles this fine), payment processing (Stripe works in browsers), and content delivery (web is superior for SEO and sharing).
The PWA Middle Ground
For founders who want the “app-like” experience without the native cost, Progressive Web Apps are worth considering.
A PWA is a web app with a few additions: a manifest file (tells the phone how to display the app icon), a service worker (enables offline caching and push notifications), and HTTPS (required for both).
Adding PWA capabilities to a web app takes 1-2 days of development time and zero additional cost beyond the base web app build. Your users can “install” the PWA from their browser — no App Store submission, no review process, no 30% Apple tax on in-app purchases.
The tradeoffs: iOS still limits PWA capabilities compared to Android. Background sync is unreliable. Push notifications on iOS PWAs work but with restrictions. And some users simply don’t know how to install a PWA — the “Add to Home Screen” flow isn’t as intuitive as tapping “Download” in the App Store.
For most B2B tools, internal dashboards, and marketplace MVPs, PWA is the sweet spot.
How to Decide: The 3-Question Framework
Answer these three questions:
1. Does your core feature require native hardware access? If yes — camera, Bluetooth, GPS background tracking, AR — go native or cross-platform. If no, web app.
2. Do your users have reliable internet? If no — offline-first is critical — go native. If yes, web app or PWA.
3. Is App Store presence a competitive requirement in your market? If your direct competitors are all native apps and your users expect the App Store experience, go cross-platform (React Native or Flutter). If not, web app.
If you answered “no” to all three, build a web app. You’ll launch faster, spend less, and learn what your users actually need before committing $20K+ to native development.
The Cost of Getting This Wrong
I’ve seen founders spend $25K on a native iOS app, wait 12 weeks for delivery, then wait another 3 weeks for Apple’s App Store review — only to discover that their core assumption about the market was wrong. Total time wasted: 4 months. Total money gone: $25K.
The same validation could have happened with a $4K-$6K web app in 3 weeks. If the idea works, you upgrade to native with confidence and real user data. If it doesn’t, you’ve lost $4K instead of $25K.
This is why scoping your MVP correctly matters so much. The platform decision should come from the scope — not the other way around.
What to Do Next
If you’re deciding between mobile and web for your MVP, start by mapping your core workflow. Write down the one thing your first user needs to accomplish. Then ask: does that workflow require native hardware access, offline capability, or App Store presence?
Nine times out of ten, the answer is no — and a web app gets you to market in weeks instead of months.
If your product has a marketing site component, check out 5 website mistakes that silently kill your lead pipeline — especially the section on mobile optimization.
Ready to scope your MVP and figure out the right platform? Book a free discovery call and we’ll map it out together.