Skip to main content
Back to Blog
6 min read

Should you build a native app or a mobile-first web app? A founder's decision tree

Not a technology debate — a business decision. When native is worth the cost, when a web app is enough, and the 5 questions that make the answer obvious.

hiringreact-nativepricing

Founders ask me "should I build an app?" and usually mean "should I be in the App Store?" Those are different questions. The first one is about mobile UX. The second is about distribution. Getting them confused costs either €15K on an app nobody needed, or 6 months of friction on a web experience that should have been native.

This post is the decision framework I walk through with every founder who asks. Five questions, each one eliminates options. By the end, the answer is usually obvious.

The 5 questions

1. Does your core feature need device hardware?

Camera, accelerometer, Bluetooth, NFC, offline storage, push notifications with high opt-in, background location tracking, biometric auth.

If yes → native. Web APIs exist for some of these, but they're unreliable across browsers, limited on iOS Safari, and often require user permission flows that kill adoption. Push notification opt-in on PWA: ~15%. On native: 60–75%.

If no → web is fine. Most B2B SaaS, dashboards, marketplaces, booking systems, and content platforms don't need device hardware. A responsive web app served from a good domain is faster to build, cheaper to maintain, and reaches every device without an install.

When I built the E7 Shop app, the answer was clearly native: seat map gestures needed 60fps on a 3,000-node SVG (browser hit 24fps), tickets needed encrypted offline storage, and push reminders drove 72% opt-in. Without those three requirements, a PWA would have been fine.

2. Is "install the app" a reasonable ask for your users?

Be honest about this. Installing an app is a commitment. Users need to:

  1. Find it in the store (or follow a link)
  2. Wait for the download
  3. Grant permissions
  4. Create an account (or log in)
  5. Figure out the interface

Each step has a dropout rate. For a tool people use daily (banking, messaging, fitness), the install friction is worth it. For something people use once a month or less (booking a dentist, checking a menu, filing an expense report), a web app with a good mobile layout is better.

Rule of thumb: If your user opens the product less than 3 times per month, native is overkill. A bookmark or home-screen shortcut does the job without the install barrier.

3. What's your launch timeline?

A mobile-first web app: 6–10 weeks for an MVP with a solo developer.

A native app (React Native, both platforms): 8–14 weeks for an MVP with a solo developer. Add 1–2 weeks for App Store review (Apple alone can take 8 days including a rejection cycle — I've been through it).

A native app with separate iOS and Android codebases: 12–20 weeks with two developers, and you now have two products to maintain forever.

If you need to launch in under 8 weeks → web first. You can always add native later once you've validated the core product. The reverse — starting with native and adding web later — is more expensive because you've already built platform-specific code that doesn't transfer.

4. What's your maintenance budget after launch?

This is the question founders forget to ask.

A web app has one codebase, one deployment, one set of dependencies. Updates ship instantly — no review process, no version fragmentation.

A native app has:

Budget expectation: A web app costs €500–€1,500/month to maintain (hosting, monitoring, minor fixes, dependency updates). A native app costs €1,000–€3,000/month for the same level of maintenance — and that's with React Native (one codebase). Two native codebases: double it.

If you're pre-revenue or early-revenue and maintaining an app would eat 20%+ of your monthly budget, start with web.

5. Is the App Store a distribution channel for you?

For some products, being in the App Store is discovery. Fitness apps, games, utilities — people search the store. "Workout timer" gets 50K searches/month. Being in the store is marketing.

For most B2B SaaS and niche products, the App Store is a delivery mechanism, not a discovery channel. Nobody searches "logistics dispatch software" in the App Store. They find you through Google, referrals, or direct sales — then you send them to the app.

If the store is discovery → native makes sense earlier. You get ASO (App Store Optimization), ratings, reviews, and a presence where users are already browsing.

If the store is just delivery → web first, native later. Build the product, get traction, and add native when users ask for it or when device features become a real bottleneck.

The decision tree (summary)

Needs device hardware (camera, offline, push, gestures)?
├── Yes → Native
└── No
    └── Users open it 3+ times/month?
        ├── Yes
        │   └── Launch timeline > 8 weeks?
        │       ├── Yes → Native
        │       └── No → Web first, native later
        └── No → Web app

If you hit "Native" in the tree, the next question is React Native or FlutterI covered that separately.

The hybrid path most founders should take

For most startups I work with, the answer is: web first, native when it earns it.

  1. Weeks 1–10: Build a mobile-first responsive web app. Launch. Get users. Validate that people actually want the product.
  2. Months 3–6: Watch usage data. If mobile users are 60%+ of traffic and you're seeing feature requests that need device APIs — plan native.
  3. Months 6–12: Build native on React Native with a shared backend. The API is already built, the data model is proven, and you know exactly which features matter.

This path costs less upfront, lets you validate before committing to native, and avoids maintaining an app that nobody downloads.

The opposite path — building native first — only makes sense when device hardware is non-negotiable from day one. E7 Shop was one of those cases. Most products aren't.

What it costs

Real numbers from my projects:

PathTimelineCost range
Mobile-first web app (MVP)6–10 weeks€6K–€12K
React Native app (MVP, both platforms)8–14 weeks€8K–€18K
Web app → add native later6–10 weeks + 8–12 weeks€14K–€25K total
Separate iOS + Android12–20 weeks€20K–€40K

The "web first, native later" path looks more expensive in total — but spread over 6–12 months, it's lower risk. You're spending the native budget after validation, not before.

Here's what a full MVP cost breakdown looks like if you want to see where the hours go.


Not sure which path fits your product? Book a scoping call — I'll tell you which I'd build and why, based on your users, timeline, and budget. No commitment, just clarity.