# Why Your MVP Doesn't Need a Mobile App (Yet)
A founder pitched me his idea for a B2B productivity tool. It was a genuinely interesting concept - a way for distributed teams to do async standup meetings with structured check-ins and progress tracking. He wanted to build it as a mobile app because he figured people would use it from their phones.
His budget was $80,000. A mobile app for this product would consume the entire budget and produce something that only ran on phones. The web alternative would cost $35,000 and work on phones, laptops, tablets, and desktops. The web version would have $45,000 left over for marketing, iteration, and responding to what users actually wanted.
He built the mobile app anyway. I don't know why founders get attached to this decision, but they do.
Eighteen months later he had 300 users, burned through his budget, and a product that couldn't be used on the computers where his users actually did their work - because his users were knowledge workers who had access to browser-based tools all day and pulled out their phones only for communication and personal use.
The Default Assumption Is Usually Wrong
The assumption that drives premature mobile app development is: "My users will use this product on their phone."
This assumption is true for some product categories. It's false for many others.
The question isn't whether your users have phones. They do. The question is whether the specific task your product helps them with is a task they want to do on their phone.
Consumer products with habitual, quick interactions: yes, mobile first. Checking their expense log, logging a workout, seeing their bank balance, messaging - these are phone behaviors.
Complex tasks requiring focus or data entry: usually desktop or laptop. Writing, data analysis, project management, business operations, coding, document review - these are computer behaviors.
B2B tools used during the workday: mostly desktop, with mobile as a secondary access point. Your users are at computers all day. They want a web app with keyboard shortcuts and large-screen layouts. Mobile access is a supplement, not the primary experience.
What "Mobile First" Actually Means in Practice
"Mobile first" as a design principle means: design for mobile screens and constraints before designing for desktop. It does not mean: build a native app before a web product.
A mobile-first web product (designed for phone browsers, with responsive layouts and touch-friendly interactions) gives your users an excellent mobile experience without the cost and complexity of a native app.
This is often the right call for your first version. You get mobile accessibility without:
- Separate iOS and Android codebases (or the complexity of a cross-platform framework)
- App Store review and approval timelines (1-3 weeks for iOS)
- App Store optimization as a required skill for distribution
- Platform compliance requirements that shift with Apple and Google policy updates
- The ongoing cost of maintaining a native app through OS updates
The Numbers: What You're Actually Choosing Between
Here's a real cost comparison I've done for multiple clients:
Web app (React/Next.js frontend + Django backend), responsive mobile design: $30,000-60,000 for a focused MVP.
Cross-platform mobile app (Flutter or React Native) + separate web backend: $55,000-100,000 for equivalent functionality.
Native iOS + Android apps + web backend: $90,000-160,000.
At seed stage with $200,000 in runway, the difference between option 1 and option 2 is 2-3 months of additional development time and $25,000-40,000 in extra cost. That's real money that could go toward user acquisition, team runway, or iterating on your product after learning from initial users.
When Mobile App First Is Actually the Right Call
I'm not saying never build mobile. I'm saying the default should be web, and you should need a good reason to deviate.
Good reasons to build mobile first:
The product is genuinely phone-native. Camera features, barcode scanning, proximity detection, push notifications as a core interaction, GPS tracking - these require native mobile capabilities that web apps can't replicate well (though web APIs are improving). If your product's core feature requires these capabilities, mobile might be right.
Offline functionality is critical. Native apps work offline in ways that web apps still struggle to match. If your users are in environments without reliable internet and need to use your product anyway - field service apps, outdoor activity tracking, remote work tools - mobile-native offline support might justify the cost.
Your distribution is app store dependent. Some categories of products reach their users primarily through App Store browsing and featured placements. Games, consumer lifestyle apps, AR experiences - if app store discovery is your primary acquisition channel, you need to be on the platform.
You're building a second product on a proven base. If you already have a web product with validated product-market fit and your analytics show significant mobile traffic or user requests for a native app, that's evidence. Build mobile then, not before you have that signal.
The Sequence That Works
The pattern I recommend for most founders:
Build web first. Get users, validate the product, understand how people use it. Your analytics will tell you what percentage of users access it from mobile browsers. The behavior will tell you what they do on mobile vs. desktop.
When you have evidence of mobile need - mobile traffic above 40%, user feedback requesting native features, product behaviors that would be better on mobile - then scope a mobile app based on what you actually know users want.
The B2B productivity founder I mentioned: if he had shipped the web version first, he would have discovered within three months that his users were using it primarily at their desks, on computers. He would have optimized for that. He might have added a mobile companion app for quick check-ins on the go. But the primary experience would have matched how his users actually worked.
Instead, he built the wrong primary experience and spent 18 months learning that lesson.
Web first is almost always right for first products. The exceptions exist - but they need evidence, not assumptions.
Book a 30-minute call: https://calendly.com/alpsf/zoom-with-aleksandr