What Is an MVP? (And How Small Yours Should Actually Be)

An MVP — minimum viable product — is the smallest version of your product that's still genuinely useful and sellable. Its job isn't to impress or to be complete; it's to prove the core idea with real users, fast, before you sink a year and a pile of money into building everything you imagine. Think of it as the cheapest, quickest way to find out if you're right.

The hard part isn't understanding the concept — it's having the discipline to make it small enough.

What "minimum" and "viable" actually mean

The two words pull in opposite directions, and that tension is the point:

• Minimum — as little as possible. The fewest features, the smallest scope.
• Viable — but still genuinely useful. It has to solve the core problem well enough that a real person will use it and pay.

An MVP lives at the intersection: the least you can build that's still worth paying for. Too minimal and it's not viable (nobody uses it). Too viable and it's not minimal (you've built a full product on a guess).

The job of an MVP: learn, not launch big

An MVP is a learning tool. You build the core, ship it to real users, and watch what actually happens — which features they use, what they ask for, whether they'll pay. That real-world feedback is worth far more than months of planning, because users always surprise you.

This is why the MVP comes right after validating the idea and before the full build — it's the bridge between "people say they want this" and "people actually use and pay for this."

Most MVPs are too big

Here's the universal mistake: founders call something an MVP, then pack it with features "we'll obviously need." That's not an MVP — it's a full product wearing an MVP label, with all the cost and risk that implies.

The discipline test: for every feature, ask "can I prove the core idea without this?" If yes, cut it. You can almost always cut more than feels comfortable. The one feature that proves the idea stays; everything else waits for the feedback that tells you it's actually needed.

A classic example: if you're building a tool to schedule something, the MVP is just the scheduling — not the analytics dashboard, the integrations, the team permissions, and the mobile app. Those come after people prove they want the scheduling.

Lean, but real — not a throwaway

One important distinction: an MVP is not a disposable prototype. A prototype is a quick mockup to test an idea internally. An MVP is a real product paying customers use. The difference matters because a good MVP shares the foundations of the full product — so when it works, you grow it by adding features, not by rebuilding from scratch. (Getting those foundations right is part of launching a SaaS properly.)

How to scope yours

1. Name the core promise — the one thing your product must do.
2. List every feature you're imagining.
3. Cut everything that isn't essential to delivering that core promise.
4. Build what's left, ship it, and let real use tell you what's next.

If the remaining scope still feels big, cut again. The smallest viable version gets you to learning fastest.

The bottom line

An MVP is the smallest genuinely-useful, sellable version of your product — built to learn whether the idea works by getting it to real users fast, not to be complete. Make it minimum (cut ruthlessly) but viable (still worth paying for), keep it real rather than a throwaway, and grow it from feedback. The biggest risk isn't shipping too little — it's building too much before you know anyone wants it.

Ready to scope yours down to the true core? That's exactly what our MVP development work does. For the full journey, see the founder's guide to launching a SaaS.