Your MVP scope

By Mathéo Ballasse · July 6, 2026

An MVP is not a cut-rate product

People often confuse an MVP with a rushed version. A minimum viable product is neither: it's the smallest version that already solves the core problem for a first user, built to learn fast rather than to impress. The point isn't to ship little out of laziness, but to put your riskiest assumption in front of reality before you've sunk months of development into it.

Why does this matter so much? Because the top cause of startup failure isn't technical, it's building something nobody wants. CB Insights' analysis of startup failure reasons puts lack of market need at the very top of the list. An MVP exists precisely to test whether there's a market before you bet everything on it. The longer you build without confronting your idea with users, the more you risk polishing something nobody was waiting for.

How to scope it: must-have, later, cut

Scoping an MVP means sorting without mercy. A feature is must-haveonly if, without it, your product no longer solves the core problem. Anything that improves, reassures or looks nice, but whose absence doesn't break the promise, goes into later. And anything that only adds work and pushes the date back without changing anything for your first user, you cut.

The right question isn't "what could I add," it's "what can I remove while still solving the problem." It's counterintuitive, because as a founder you see a thousand possibilities and want all of them. But every extra feature is one more week of dev, one more potential bug, and above all one more day your launch gets pushed back. The tool does this sorting with you and puts a "why" on every call so you can push back on it.

The perfectionism trap

The classic founder trap is pushing the launch back feature after feature, telling yourself "just this one more and it'll be ready." Except it's never ready, because there's always one more feature to imagine. Meanwhile, nobody is using the product and you're learning nothing. The real risk early on isn't launching an incomplete product, it's never launching at all.

There's a deeper reason to cut things short. Building the product is only 20 to 30% of the road to a working SaaS; the remaining 70 to 80% is distribution, finding users and convincing them. Every week spent polishing a feature is a week not spent talking to customers. Launching early with a tight scope isn't settling for less, it's freeing up time for the real work waiting for you afterward.

A worked example of the sort

Say you're building a rank-tracking tool for SEO agencies. Your head is full of ideas: a real-time dashboard, white-label reports, Slack alerts, an API, a mobile app, AI-generated keyword suggestions. Run each one through the must-have filter. Does tracking positions for a list of keywords solve the core problem? Yes, that's must-have. Does a basic, readable client report solve it? Yes, also must-have. Does a fully customizable white-label report solve it? No, a plain one does the job for now, so it goes to later. Does a real-time dashboard with ten filters solve it? No, and it adds real complexity, so it gets cut. A mobile app and AI keyword suggestions follow the same fate: nice ideas, zero contribution to the core problem on day one.

What's left after the sort is often startlingly small: track a list of keywords, output a clean report, handle a basic account and billing. That's not a lesser product, that's the product, stripped of everything that doesn't need to exist yet. And that's exactly the kind of scope the tool above will hand you for your own idea, worked out the same way.

The smallest shippable thing

Beyond the sorting, the tool gives you one precise thing: the smallest thing you could actually ship. Not your ideal MVP, but the minimal version you could put in front of a few users this week or next month, even if it's rough and you fill the gaps by hand. Often, this version is much smaller than what you imagined, and that's good news: the less there is to build, the faster you learn.

The risk to test before you build

Every MVP rests on one bet that's riskier than the others. Sometimes it's "do people really have this problem," sometimes "will they change their habits for my solution," rarely technical feasibility. The tool flags this risky assumption, because it's the one you need to test first, ideally before you write much code at all. If the bet is wrong, no feature will save you; if it's right, you can build with confidence.

Finally, a word on timeline. The tool gives you a rough estimate, deliberately conservative. A minimal scope should be counted in weeks, not months; if your MVP needs six months, it's almost certainly too broad. But watch out for overly optimistic estimates: technical unknowns always drag timelines out. Aim small, keep a buffer, and remember that the launch date is the goal, not completeness.

The signal that tells you to stop adding

There's a moment when you know, deep down, that you're adding features to reassure yourself, not because your users are asking for them, simply because you don't have any yet. That moment is exactly the signal to launch. The feeling of being ready never comes on its own: it comes from real users using your product and telling you what's missing. As long as you keep building in a vacuum, you're delaying that feedback, and with it the only learning that counts.

A simple rule helps you decide: if a feature can be replaced by you, doing it by hand, for the duration of the launch, it isn't must-have. Many SaaS companies started with a founder manually doing what the product would later automate. It's ugly, it doesn't scale, and it's exactly what you should do to learn fast without overbuilding.

Scoping mistakes that quietly kill launches

The first mistake is scoping from your imagination instead of the problem. It's tempting to build what would impress other founders on LinkedIn, not what a first user actually needs to get value. If you catch yourself justifying a feature with "it would look more professional" rather than "without it, the problem isn't solved," that feature belongs in later, not must-have.

The second is confusing polish with scope. A must-have feature can still be ugly. Your billing can be a manual invoice, your onboarding can be a five-minute call, your report can be a plain PDF with no branding. None of that shrinks the scope, it just means you're not spending time on things a first user won't judge you for. Polish is a later problem, scope is a now problem, and mixing the two is how a two-week MVP turns into a two-month one.

The third is scoping for scale you don't have yet. Worrying about what happens at 10,000 users when you don't have ten is a common way to avoid the harder, scarier work of getting your first users at all. Build for the five or ten people you can actually reach by hand. You can always rebuild for scale once you know the product is worth scaling, and rebuilding a proven product is a far better problem to have than perfecting one nobody wants.

The fourth is treating the cut list as final. Cutting a feature for launch doesn't mean abandoning it forever, it means refusing to let it block the moment you learn whether your core idea works. Keep your later and cut lists visible. They become your actual roadmap once real users start telling you which of those items they'd pay more to get, which is a far more reliable prioritization signal than anything you could guess today.

Frequently asked questions

What is an MVP?

An MVP (minimum viable product) is the smallest version of your product that already solves the core problem for a first user. It's not a cut-rate product or a demo: it's a real product, stripped to the essentials, built to test your riskiest assumption with real people instead of building blind.

How do you define your MVP scope?

Start from the core problem, not your list of ideas. A feature is must-have only if, without it, the product doesn't solve that problem. Everything else goes into "later" or "cut." The right question isn't "what could I add" but "what can I remove while still solving the problem."

How many features should an MVP have?

As few as possible. An MVP often fits in one or two features that work well, not ten that half-work. If you're hesitating to cut a feature, it probably belongs in "later." You can always add it once you have users asking for it, which is a far better signal than your gut feeling.

How long does it take to build an MVP?

It depends heavily on the product and your speed, but the goal is to count in weeks, not months. If your scope needs six months of development, it's almost always too broad. The sooner you launch, the sooner you learn, and learning matters more than completeness at this stage.