Where the term comes from (and why it's been so badly misunderstood)
Eric Ries coined "MVP" in The Lean Startup in 2011. The idea was simple: instead of spending 18 months building the perfect product, spend 8 weeks building the most important slice of it, get it in front of users, and learn. Then iterate.
Fifteen years later, the term has been stretched so far that founders use it to describe everything from a Figma mockup to a fully-featured SaaS app. That confusion is expensive. We've spoken to hundreds of founders who've burned through £50K–£200K building something that was never a true MVP — it was a wish list with a shorter timeline.
What an MVP is not
Before the definition can do any work, it's worth clearing the field.
An MVP is not a prototype. A prototype is a model used to test a concept. It doesn't have to work. An MVP has to work — for real users, in real conditions, even if it only does one thing.
An MVP is not a "beta." Beta implies a full product with known bugs. An MVP is deliberately scoped to do less. It's not unfinished — it's purposefully narrow.
An MVP is not the cheapest thing you can get away with. Some founders equate "minimum" with "minimum effort." The minimum refers to scope, not quality. A slow, unreliable product that crashes isn't an MVP — it's a liability.
An MVP is not a pitch deck. We've had founders come to us who've been told by agencies that a landing page and a video constitute an MVP. They don't. An MVP is something users can actually use.
The three things every MVP must do
If your MVP doesn't do all three of these things, it isn't an MVP yet:
1. Solve one real problem for one real user. Not five problems. Not a broad market segment. One clearly defined problem, for a person you've actually spoken to. Everything else is scope creep.
2. Deliver that solution in a way users can access independently. An MVP that requires you to be in the room to make it work isn't an MVP — it's a consultancy project. The user should be able to sign up, use it, and get value without you holding their hand.
3. Generate a signal you can act on. This is the part most people skip. An MVP isn't just about shipping — it's about learning. Before you build, you need to know what question you're trying to answer. Are users signing up? Are they coming back? Are they willing to pay? The MVP should be designed to answer one of these questions clearly.
Real examples of MVPs that got it right
Airbnb launched with a basic website, no booking system, and photos taken on a personal camera. The founders manually coordinated everything. That was enough to prove people would pay to stay in a stranger's home. Once that was proven, they built the platform.
Dropbox didn't build a product first. They built a three-minute explainer video showing how it would work and published a sign-up page. 75,000 people joined the waitlist overnight. That was their MVP — enough signal to justify building.
Uber launched in San Francisco only, with only black cars, and the app only worked on iPhones. No surge pricing, no driver ratings, no city-wide coverage. They scoped it to the smallest possible version that could test the core assumption: would people pay for on-demand rides?
The pattern in all three cases is the same: they identified the one assumption their entire business model depended on, and they built the minimum thing needed to test it.
The most common mistake founders make when defining their MVP
They start with features, not problems.
The conversation we have most often with first-time founders goes something like this: "We need push notifications, a dashboard for admins, three user types, in-app messaging, Stripe integration, an API for partners, and a mobile app for iOS and Android." That's not an MVP. That's a Series A product roadmap.
The right question isn't "what features do we want?" — it's "what's the one thing a user needs to do for us to know this product has legs?" Work backwards from that.
How to know when your MVP is ready to launch
An MVP is ready when it does exactly one thing well, your first ten users can complete that thing without your help, and you know what metric you're watching to decide whether to continue building.
It is not ready if you're embarrassed to show it to users. Done well, an MVP should make you slightly uncomfortable — not because it's broken, but because it's so much smaller than your vision. That's a feature, not a bug. The gap between your vision and your MVP is where you learn whether your vision is right.
What it takes to actually build one
Most founders underestimate how long scoping takes relative to building. Getting the scope right — deciding what's in and what's out — is arguably the most important part of the process. A week of clear thinking at the start saves months of wasted build time.
At The MVP Studio, we spend the first two weeks of every project on exactly this: a Blueprint phase where we define the problem, scope the product, map the user flows, and agree on what success looks like before a single line of code is written. It's unglamorous. It's also the reason we can deliver in 100 days.
If you're trying to scope your MVP and keep adding features, book a free scoping call. We'll tell you in 30 minutes what belongs in v1 and what can wait.
Quick-reference: MVP definition checklist
- Does it solve one clearly defined problem?
- Can a real user access and complete the core flow independently?
- Is there a specific question this MVP is designed to answer?
- Has any scope been cut because it wasn't essential to that question?
- Do you know what metric will tell you whether to continue?
If you answered yes to all five, you're scoping a real MVP. If not, keep cutting.