“An MVP is not a cheap version of your product. It is the smallest thing you can build to find out if your product should exist at all.”
The founding principle behind lean startup methodologyWhat Is an MVP, Exactly?
An MVP - minimum viable product - is the simplest version of your product that lets you test a core assumption with real users. The goal is not to build something small and ship it fast because you're lazy. The goal is to learn something specific before investing months of budget into the wrong thing.
The term was popularised by Eric Ries in The Lean Startup, but the idea is older than that. You build the minimum amount needed to answer one question: will real people pay for this, use this, or care about this? If the answer is yes, you now have evidence to justify building more. If the answer is no, you've saved yourself a year of wasted effort.
What an MVP is not: a buggy prototype you apologise for, a landing page with no real functionality, or a full product with one feature removed. It is a working, releasable thing - just scoped tightly around one user problem.
The Classic MVP Examples Worth Knowing
Dropbox did not build a product first. They built a three-minute explainer video showing how the product would work. Signups came in overnight. That video was their MVP - it validated demand before a single line of cloud storage code was written.
Airbnb's founders rented out air mattresses in their own apartment to test whether strangers would pay to sleep in someone else's home. No platform, no payments system, no app. Just a simple test of the most uncertain assumption in their business.
These examples matter because they show that an MVP does not have to be software at all. It has to answer your riskiest question with the least possible investment. Your riskiest question is usually: does anyone want this?
What Goes In and What Stays Out
Deciding what belongs in an MVP is where most founders struggle. The instinct is to add features because they seem important or because a potential user mentioned them once. That instinct will sink your launch timeline and blur your learning.
A useful filter: every feature in the MVP must either deliver the core value your product promises, or be required for the product to function at all. Anything else is scope creep. Notifications, referral programmes, admin dashboards, multi-language support - none of these are MVP features unless your core product literally cannot work without them.
- The one action your product is fundamentally built around (the core loop)
- Enough onboarding for a stranger to understand what to do
- Basic authentication if user accounts are central to the value
- Payment or commitment mechanism if you're testing willingness to pay
- A way to collect feedback or measure whether the core action happened
- Error states that don't leave users stranded
Common MVP Mistakes That Delay Everything
The most common mistake is building an MMP - minimum marketable product - and calling it an MVP. An MMP is polished enough to market to a broad audience. An MVP is rough enough to be embarrassing, but functional enough to teach you something. If you're not a little uncomfortable shipping it, it's probably not an MVP.
The second common mistake is not defining success metrics before you build. If you launch and then try to figure out what the results mean, you'll interpret everything as validation. Decide beforehand: 100 sign-ups means yes, 12 means no. Then hold yourself to it.
The third mistake is building in isolation for too long. Founders often delay showing the MVP to real users because it feels unready. Every week you wait is a week of feedback you're not getting. Ship ugly. Learn fast.
How Long Should an MVP Take to Build?
For a web or mobile app, a well-scoped MVP should take 6 to 12 weeks with a focused team. If your MVP is taking longer than three months, the scope has crept or the definition was never tight enough to begin with.
When to Rebuild vs. When to Iterate
After your MVP, you will have one of three results: clear validation (build more), clear failure (pivot or stop), or ambiguous signal (which usually means you either measured the wrong thing or released to the wrong audience). Most founders get the third result and mistake it for validation.
If users are signing up but not doing the core action - your conversion is broken, not your idea. If users are doing the core action but not coming back - retention is the problem, not acquisition. Each of these points to a different next build, and knowing which one to tackle next is the whole value of the MVP process.
Where Founders Get Stuck in Practice
Many founders today start their MVP with AI tools - Lovable, Bolt, Cursor, v0 - and get surprisingly far. The UI looks real, basic flows work, and it feels like an MVP. Then they try to connect real payments, add proper authentication, or prepare for actual user load, and things start breaking in ways that are hard to debug without a developer.
This is a real pattern we see regularly. The MVP exists, users are interested, but the product is sitting on a foundation that wasn't built to scale or to secure real user data. Getting from that state to a shippable, production-grade app is exactly what Zovintra's Launch & Rescue service is designed for. If you've validated your idea and now need to build it properly - or rescue a prototype that's gotten stuck - that's a conversation worth having.
