The Original Definition
Eric Ries defined it in The Lean Startup: "the version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort."
Three words, three requirements:
- Minimum: Only the features needed to test your core hypothesis. Nothing extra.
- Viable: It must work. Not crash. Not feel broken. Users need to be able to use it under real conditions.
- Product: Not a mockup. Not a slide deck. A deployed, usable product.
The word people get wrong is "minimum." Minimum does not mean bad. It means focused. An MVP solves one problem well. It deliberately ignores everything else.
What Changed in 2026
The definition has not changed. The timeline has.
In 2020, an MVP took 2-3 months and $15,000-$50,000. In 2026, a solo developer with AI tools can ship an MVP in a weekend. The barrier dropped by 100x.
This sounds like good news. It is — with a caveat. Cheaper MVPs mean more MVPs. More MVPs mean more noise. The differentiator is no longer speed of development. It is depth of problem understanding.
YC partner Michael Seibel puts it directly: "An MVP should be embarrassingly simple. But it should solve a real problem for a real person."
The Mistake I See Most
Builders in 2026 skip validation entirely. AI makes building so fast that they jump straight to a "full product" without testing whether anyone wants it.
This is worse than building a slow MVP. At least a slow MVP forces you to think carefully about what to include. When building is instant, people include everything. They ship a bloated app that solves no specific problem well.
The discipline of an MVP is not about technical constraints. It is about forcing yourself to articulate: what is the one thing this product must do? If that one thing does not resonate with users, adding 20 more features will not help.
MVP for Mobile Apps
Mobile MVPs have a specific challenge: App Store review.
Apple requires every feature described in your metadata to work. No "coming soon" sections. No placeholder screens. No broken flows. An MVP on the App Store needs to be polished enough to pass review while remaining focused enough to test one hypothesis.
This is where a boilerplate changes the math. Auth, payments, push notifications, deployment — all handled. Your MVP effort goes entirely to the one feature that tests your hypothesis, not to infrastructure.
I shipped my first app as an MVP: one core feature, clean UI, working auth, push notifications. Took 4 days with the boilerplate in place. Without it, the infrastructure alone would have taken 3 weeks.
When to Stop Adding Features
Ship when your product does one thing and does it well enough that a stranger would use it. Not your friend. Not your mom. A stranger who has the problem you are solving.
If they use it and come back, you have something. If they do not come back, no amount of additional features will fix the core problem. Go back to talking to users.