Mobile App or Web App First? How I Help Founders Decide for an MVP

"Should we build a mobile app or a web app first?" I hear this on almost every first call with a founder. The answer depends on your users, your budget and how fast you want to learn.

I posted a short take on LinkedIn about this, and a few founders asked me to go deeper. So here is the longer version: what I usually recommend, when I recommend the opposite, and a simple checklist you can use before you talk to any developer, including me.

The short answer

• Most MVPs should start as a web app. It's faster to change, easier for people to try, and simpler to charge money through.
• Go mobile first when the product only makes sense on a phone. Things like push notifications, camera, background location and offline use.
• Avoid building both at the same time on an MVP budget. Pick one, learn from real users, then add the other.

Why I usually say web first

You can fix things the same day

Your first version will have bugs. Some screens will confuse people. You'll find out the onboarding asks too many questions. That's normal, and the whole point of an MVP is to find these things and fix them quickly.

With a web app, I push a fix and it's live for everyone within minutes. Nobody has to update anything. With a mobile app, every change goes through Apple's and Google's review process before users can get it, and even after it's approved, some users will keep the old version for a while because they don't update their apps. You don't control that timing, and it adds friction to every small change.

People can try it from a link

Early on, you're asking strangers for a few minutes of their time. A link is the lowest possible barrier.

An app asks for more. Go to the store, download, wait, open, create an account. Every step loses people. When you're trying to figure out if anyone wants the thing at all, you want as few steps as possible between curiosity and the first real use.

Payments are simpler

On the web, you can use Stripe (or a similar provider) and you're done. You control pricing, trials, coupons and how the checkout looks.

Inside a mobile app, Apple and Google have rules about selling digital goods and subscriptions, and in many cases you have to use their in-app purchase system and give them a share of the revenue. These rules have been changing in different countries, so I always check the current guidelines for each project. But on day one, it's extra work and extra decisions you probably don't need.

When mobile first is the right call

Some products would just be worse on the web. I'd go mobile first when your core feature depends on things a phone app does much better:

• Push notifications that people rely on. Reminders, alerts, chat messages. If the product is useless when users miss a notification, you want native push.
• Camera as a main feature. Scanning documents, taking photos of receipts, recording video. Browsers can use the camera, but an app gives you a smoother and more reliable experience.
• Background location. Delivery drivers, field workers, fitness tracking. A website can't keep tracking location when it's closed. An app can, with the user's permission.
• Offline use. If your users work in places with bad signal, like warehouses, construction sites or rural areas, a native app handles this better.
• Phone-only habits. Habit trackers, quick daily check-ins, anything people open many times a day for a few seconds. Those belong on the home screen.

A simple test I use: picture your ideal user using the product. If they're standing, walking or driving, think mobile. If they're sitting at a desk, think web.

If you go mobile, use one codebase

When a project needs a mobile app, I usually build it with React Native. One codebase covers both iOS and Android, so you're not paying for two separate apps or waiting for one platform to catch up with the other.

There's another benefit later. React Native uses JavaScript and TypeScript, the same as Next.js, which is what I use for most web apps. So when you add the web version, a good part of the logic can be shared: things like data types, validation rules, API calls and business logic. The screens themselves are mostly built separately, because a phone screen and a desktop browser need different layouts anyway. But you're not starting from zero.

The middle option: a PWA

A Progressive Web App, or PWA, is a web app that can behave a bit like a phone app. Users can add it to their home screen, it opens without the browser bar, and it can work offline to some degree.

It's a good fit when you mostly need a web app but want it to feel more at home on a phone. You keep all the web benefits: instant updates, sharing by link, Stripe for payments. And you skip the app stores for now.

It has real limits though, and I always explain them upfront:

• On iPhone, web push notifications only work after the user adds the app to their home screen, and many users never do that.
• No background location. The app can only use location while it's open.
• Camera, file and device access is more limited than in a native app.
• You're not in the App Store or Play Store, so people won't find you there.

For a lot of MVPs, those limits don't matter yet. If your test is "will people use this every week?", a PWA can answer that without the cost of a native app.

Why not build both at once?

But building web and mobile together on an MVP budget usually means two things to design, two things to test, two sets of bugs, and two release processes. And the money spent on the second platform is money you're not spending on figuring out what users actually want.

Most products change a lot after the first real users touch them. It's much cheaper to make those changes in one place. Once the core flow works and people keep coming back, adding the second platform is a much safer bet, and you'll know exactly what it needs to do.

A simple decision checklist

Answer these honestly before your first call with a developer:

• Where will people use it? At a desk, lean web. On the move, lean mobile.
• Does the core feature need push, camera, background location or offline? If yes to any of these, and it's central to the product, lean mobile.
• How will your first users find you? If it's through links, outreach and your network, web makes trying it much easier.
• How will you charge? If you're selling a digital subscription, web keeps payments simpler at the start.
• How often will you need to ship changes? If you expect to change things every week (most MVPs do), web gives you the fastest loop.
• Would a PWA cover it? If you want a phone-friendly experience but don't need deep device features, try a PWA first.
• Can you afford to maintain two products? If the honest answer is no, pick one.

If most of your answers point to web, start with a Next.js web app, make it work well on phones, and add React Native later. If they point to mobile, start with React Native and keep the backend ready for a web version.

Conclusion

There's no prize for launching on every platform. The goal of an MVP is to put something real in front of users and learn as fast as possible. For most founders, that means web first. For some, it clearly means mobile. The right answer comes from how and where your users will actually use the product.

If you're stuck on this decision for your own product, send me a message on LinkedIn. I'm happy to look at your idea and tell you honestly which way I'd go.