The term "MVP" has been so thoroughly misused that it now means almost nothing. We've seen founders use it to justify shipping products with broken flows, missing error states, and no real user validation. We've also seen the opposite — teams spending 18 months building a "minimum" product that could have been validated in 8 weeks.
Both are wrong. Here's what an MVP actually is.
The definition that actually holds up
An MVP is the smallest thing you can build that lets you learn whether the core assumption behind your business is true.
That's it. Not "a version 1.0." Not "a prototype." Not "the app without the nice-to-haves." It's a learning instrument.
The question you have to answer before writing a line of code: what is the riskiest assumption in our business, and what's the cheapest way to test it?
What a good MVP looks like in practice
Good MVPs share a few characteristics:
They test one thing. Not five. Not the whole product vision. One assumption. "Will users pay for this?" is a testable hypothesis. "Is our product good?" is not.
They are fully complete within their scope. An MVP that has one feature and that feature crashes is a bad MVP. An MVP with one feature that works perfectly, converts, and teaches you something is a good one. Quality within a narrow scope beats breadth at low quality every time.
They have a clear success criterion set before launch. "50 paid signups in the first month" is a success criterion. "People seem interested" is not.
They reach actual target users. Testing with your friends or colleagues is almost always misleading. The hard work is getting the MVP in front of strangers who have the problem you're solving.
The cuts that kill MVPs
The most dangerous cuts are the ones that remove the feedback mechanism — not the ones that reduce scope.
Cutting the analytics? You won't know what happened. Cutting the onboarding flow? Users will churn before they see the value. Cutting the error handling? Users will hit a wall and leave without telling you why.
These aren't "nice-to-haves." They're load-bearing parts of the learning structure.
What you can cut: the fifth service tier, the admin dashboard, the public API, the mobile app, the social sharing feature. If it's not on the critical path between "user arrives" and "user understands the core value," it can wait.
A practical scoping exercise
Take your full feature list. For each item, ask:
- Does removing this prevent a user from experiencing the core value?
- Does removing this prevent you from learning whether the core assumption is true?
If the answer to both is no — cut it.
If you end up cutting everything and there's nothing left, that's useful information. It means you haven't identified what the core value actually is yet. Go back and find it before you start building.
The timeline question
How long should an MVP take? Our rule of thumb: if it's taking more than 10 weeks, either the scope has grown or the core value isn't clear enough.
Most of the MVPs we've helped build shipped in 6 to 8 weeks. That's not because we rush — it's because we hold the scope line aggressively.
The discipline of scoping is a skill. It gets easier with practice. And it's the single highest-leverage thing you can do for your startup in the early stage.
We help early-stage teams scope and ship MVPs quickly. If you'd like to talk through what your first version should look like, get in touch →