Product & Features June 19, 2026 10 min read

How to Build an MVP That Actually Validates Your Idea

Most MVPs fail not because the idea is bad, but because they test the wrong thing, build too much, or launch to the wrong audience. Here is how to build an MVP that gives you real answers.

Lars Krueger

Founder & CEO

The concept of an MVP (Minimum Viable Product) has been so thoroughly adopted — and so thoroughly misunderstood — that most "MVPs" are neither minimum nor viable.

A minimum viable product isn't a stripped-down version of your full product. It's the smallest possible experiment that tests your riskiest assumption.

Why Most MVPs Fail

They build too much

According to CB Insights' analysis of startup failure^[1], "no market need" is the number one reason startups fail, accounting for approximately 35% of failures. Building too much before validating demand means you've invested months in features nobody asked for.

A common pattern:

Founder has an idea
Founder writes a 50-page spec
Development takes 6 months
Product launches with 40 features
Users ignore 38 of them
Founder runs out of money before discovering which 2 matter

They test the wrong thing

An MVP should test your riskiest assumption — the thing most likely to be wrong. For most products, that's not "can we build it?" It's:

Will people pay for this? (Demand risk)
Can we reach the right users? (Distribution risk)
Will users come back after the first use? (Retention risk)
Can we deliver this profitably? (Unit economics risk)

Building a full product tests none of these efficiently. A landing page with a signup form tests demand. A prototype with 10 users tests usability. A concierge MVP (manually delivering the service) tests willingness to pay.

They optimize too early

Spending weeks on performance optimization, pixel-perfect design, or edge case handling before proving that anyone wants the product is expensive procrastination.

Eric Ries, who popularized the term MVP in The Lean Startup, described it as the version that allows a team to collect the maximum amount of validated learning with the least effort. The emphasis is on learning, not on product quality.

The MVP Spectrum

Not every MVP involves writing code. Choose the right type for what you're validating:

1. Landing Page MVP (Tests demand)

What: A page describing your product with a signup/waitlist button.

Validates: "Are people interested enough to give me their email?"

Cost: Hours to build, minimal ad spend to drive traffic.

When to use: When you're not sure if anyone wants what you're building.

2. Concierge MVP (Tests value delivery)

What: Manually deliver the service to a small number of users.

Validates: "Does solving this problem create enough value for people to pay?"

Cost: Your time. No code required.

When to use: When you need to understand the problem deeply before automating.

3. Wizard of Oz MVP (Tests the experience)

What: Build the interface but handle the backend manually.

Validates: "Does the user experience work?"

Cost: Some frontend development, significant manual labor.

When to use: When the user experience is the riskiest part of your hypothesis.

4. Single-Feature MVP (Tests core value)

What: Build one feature — the one that delivers your core value proposition — and nothing else.

Validates: "Does this specific feature solve the problem well enough?"

Cost: 2-6 weeks of development, depending on complexity.

When to use: When demand is validated and you need to prove you can deliver value technically.

How to Scope a Software MVP

If you've validated demand and need to build actual software, here's the framework:

Step 1: State your hypothesis

Write it down: "I believe [target users] will [pay for / use / switch to] [product] because [reason]."

If you can't fill in every blank, you're not ready to build.

Step 2: Identify the core loop

Every product has a core loop — the repeated action that delivers value:

SaaS: Create → Use → Get Result → Repeat
Marketplace: Browse → Find → Purchase → Review
Social: Create Content → Share → Get Feedback → Repeat

Your MVP must complete this loop end-to-end. Everything else is optional.

Step 3: Write user feature requests for the core loop only

Your MVP should fit in 5-10 user feature requests. If you have more, you're building too much.

Example for an invoicing tool:

As a freelancer, I want to create an invoice with line items so I can send it to my client
As a freelancer, I want to send the invoice by email so the client receives it
As a freelancer, I want to see if the client opened the invoice so I know they received it
As a freelancer, I want to mark an invoice as paid so I can track my income
As a freelancer, I want to see my unpaid invoices so I know what's outstanding

That's it. No dashboard, no recurring invoices, no multi-currency, no integrations, no templates. Five feature requests. Maybe 20-30 effort units.

Step 4: Define success criteria before building

How will you know if the MVP succeeded? Define it upfront:

"10 paying customers within 30 days of launch"
"50% of beta users complete the core loop at least 3 times"
"NPS score above 30 among first 50 users"

Without success criteria, you'll rationalize any outcome as a win.

Step 5: Set a time and budget cap

Research by the Standish Group (CHAOS Report)^[2] consistently finds that smaller projects succeed at significantly higher rates than large ones. Their data shows that projects under $1 million in budget have a success rate roughly three times higher than projects over $10 million.

Set a hard cap: "We will spend no more than X euros and Y weeks on this MVP." If you can't validate within that constraint, your MVP scope is too large.

Common MVP Mistakes

Mistake 1: Building for scale before you have users

"But what if we get 100,000 users in the first week?" You won't. And if you do, that's the best problem you'll ever have — and it's solvable.

Building for scale on day one means spending 3x the development time for capacity you won't need for months or years.

Mistake 2: Adding "just one more feature"

Every feature you add before launch delays the most important thing: getting real user feedback.

The feature you're agonizing over is probably not the thing that will make or break your product. Ship without it, measure, then decide.

Mistake 3: Perfecting the design

According to research by Google^[3], users form opinions about a website's credibility within milliseconds, but this is about basic visual competence — not pixel-perfect design.

A clean, functional interface is necessary. A polished, branded, animated interface is a nice-to-have that can come after validation.

Mistake 4: Building features based on assumptions

You assume users need a dashboard. You assume they want email notifications. You assume they'll use the mobile app.

Don't assume. Launch with the minimum, watch what users actually do, and build what they actually need.

Mistake 5: Not talking to users before building

The Mom Test by Rob Fitzpatrick should be required reading before building any MVP. Talk to potential users about their problems — not your solution — before writing a single line of code.

After Launch: Measure What Matters

Activation

What percentage of signups complete the core action? If users sign up but never create their first [invoice / project / listing], your onboarding is broken or your value proposition is unclear.

Retention

Do users come back? A product with 1,000 signups and 50 active users after 30 days has a retention problem. According to Mixpanel benchmarks^[4], average retention rates vary significantly by category, but anything below 20% at day 30 needs attention.

Revenue (or willingness to pay)

The ultimate validation: will people give you money? If you're pre-revenue, at minimum validate willingness to pay through surveys, pre-orders, or pilot programs.