For founders
Mobile first or web first? How I decide
Not by trend. Three questions decide it: where the user is when they need the product, how long each session lasts, and who pays. For most MVPs the answer is a responsive web app first, with native when the phone's sensors or offline use matter.
Prashant Kumar Singh · · 4 min read
In short
- Three questions: where is the user when they need it (desk: web; anywhere else: mobile), how long is a session (short and frequent: mobile; long: web), and who pays (buyers and admins live on web).
- Most MVPs: a responsive web app first. Native when the phone's camera, location, notifications or offline use are the product.
- Not sure? Responsive web, then watch where sessions actually happen.
"Should we build the app or the web version first?" comes up in most teardowns, and the founder usually already has an answer based on what they use most or what investors mentioned last. Neither is a reason. Here are the three questions that are, and how they resolve for the common cases.
Question 1: where is the user when they need it?
At a desk, with a keyboard, doing their job: web. Anywhere else, standing up, in a vehicle, in a shop, on site, in bed: mobile. The product should be on the device the user already has in their hand at the moment of need. A field-service tool is mobile because the technician is in a basement. An analytics tool is web because the analyst is at a desk with two monitors. Most products are clearer than they first seem once this question is asked precisely.
Question 2: how long is a session?
Short and frequent, a few seconds many times a day, checking, logging, replying: mobile, because the phone is always there and the cost of opening it is nothing. Long and deliberate, writing, configuring, analysing, building: web, because the screen and keyboard are what make a long session productive. A product with both kinds of session usually has two user types, which leads to the third question.
Question 3: who pays?
The person who buys, configures and administers the product almost always does it on web. Billing, team management, settings, reports, integrations: desk work. If the paying user and the daily user are different people, the paying user's flow is web and it comes first, because without it there is no revenue to justify the mobile build. A consumer product where the user pays for themselves is the exception, and there question one usually decides.
| Signal | Web first | Mobile first |
|---|---|---|
| Where | At a desk | Anywhere else |
| Session | Long, deliberate | Short, frequent |
| Who pays | An admin or buyer configures it | The daily user pays for themselves |
| Needs | Keyboard, large screen, multiple windows | Camera, location, notifications, offline |
Why most MVPs are a responsive web app
A responsive web app works on both devices, ships from one codebase, needs no app-store review, updates instantly, and can be opened from a link, which matters enormously for a product nobody has heard of yet. It covers every row of the web column and most of the mobile column. The cases where it does not are specific: the product is the camera, the location, the push notification or the offline mode. Those are native from day one. Everything else is a web app that can become native once demand is proven and the phone-specific needs are known.
The mistake to avoid
Building both at once. Two codebases, two designs, two sets of bugs, for a product that has not yet proven anyone wants it on one. If the answer to the three questions is mixed, pick the side that pays, build that, and let the other side's first version be the responsive view of the same app. That is the MVP cut applied to platforms.
Questions people ask
- Should a startup build a mobile app or a web app first?
- Decide by where the user is when they need it, how long a session lasts, and who pays. Most MVPs should start as a responsive web app; native comes first only when the camera, location, notifications or offline use are the product.
- When does a product need a native mobile app?
- When the phone's hardware is the product: camera-based capture, location tracking, push-driven workflows, or reliable offline use. Otherwise a responsive web app added to the home screen covers most needs.
- Is it a mistake to build mobile and web at the same time?
- Usually. Two codebases double the cost and bugs for a product that has not proven demand on one. Pick the side that pays, build it, and let the other be the responsive view of the same app.
If you're a founder
Send the product and the three questions get answered in the free teardown, with the platform recommendation and what it changes about the scope.
If you run an AI lab or data team
Environment choice for tasks has the same structure: pick the one platform the task is really about, pin it, and do not build the task for two at once.
Sources