How to build an MVP that actually tests your idea

An MVP is not a small version of your full product.

That's the most common misconception in early-stage building — and it's what causes founders to spend four months on something that still doesn't tell them if anyone wants what they're making.

A minimum viable product is the smallest thing you can build that answers a specific question about your market. That's it. The question comes first. The product serves the question.

The question your MVP needs to answer

Before you write a single line of code, write down the one question your MVP must answer.

Not "will people like this?" — too vague. Not "is this technically feasible?" — wrong stage.

The right question is usually one of these:

• "Will strangers pay to solve this specific problem?"
• "Do people have this problem badly enough to change their current behavior?"
• "Can I acquire a customer for less than they're worth?"

If you don't know which question you're answering, you can't know what to build. And if you can't define what a "yes" answer looks like before you launch, you'll rationalize any result as positive.

What makes an MVP too big

Most MVPs fail the "minimum" test, not the "viable" test.

Signs your MVP is too big:

• It took more than 6 weeks to build
• It has more than one core user action
• You added features because "users will probably want this"
• You haven't talked to a single potential customer since you started building

Every feature you add before you have signal is a bet you haven't earned the right to make. The market doesn't care about your roadmap. It only responds to what you've shipped.

How to validate a SaaS idea covers the signal-gathering that should happen before you build anything — including the MVP. If you haven't done that research, do it first.

The four types of MVP

1. The concierge MVP

You manually deliver what the software would eventually do.

A founder building an AI scheduling tool emails back users with schedule recommendations instead of running an algorithm. The user doesn't know it's manual. You learn exactly what output they find useful before you build the engine.

Time to build: 1 day. Information value: extremely high.

2. The Wizard of Oz MVP

The front end works. The back end is a person.

Users submit a form. You do the processing manually and return a result. You learn what inputs users provide, what results they find useful, and whether they come back — all without building automation.

Time to build: 2-5 days. Information value: high.

3. The landing page MVP

A page that describes the product and has a real call to action. Not "sign up for the waitlist" — something that costs the user something.

Pre-order for a discount. Pay a deposit. Book a call where you explain exactly what they're getting. If they won't take the action, they don't want it badly enough.

Time to build: 1-2 days. Information value: medium (measures intent, not usage).

4. The smoke test MVP

You describe the product to your target customer as if it exists and measure their response. A forum post. A cold email. A direct message. An ad.

If nobody clicks, nobody responds, nobody asks "when is this ready" — that's signal. Absence of interest is data.

Time to build: hours. Information value: medium (measures demand, not willingness to pay).

The one metric your MVP must measure

Most founders track the wrong thing: signups, page views, likes, comments.

These measure curiosity. Curiosity does not predict revenue.

The one metric that matters: the action that costs the user something.

Pre-payment. A 45-minute call booking. Submitting detailed information. Referring a colleague.

If the user will not do the thing that costs them something, your MVP has not validated demand. It has validated that people are polite when you ask them about your idea.

How to validate demand in 24 hours is the fastest version of this — a single-day sprint with a clear pass/fail threshold before you commit to building.

What to do when your MVP doesn't get traction

First: confirm it's a signal problem, not a reach problem.

If 3 people saw your MVP, the result is not statistically meaningful. If 300 people saw it and nobody responded — that's signal.

Second: check what you were testing.

Did your MVP actually answer the question you defined? Or did you drift into building features and lose sight of the validation goal?

Third: kill it or change the question.

The fastest way to kill a bad idea before you waste months lays out the kill criteria framework in detail. The point is this: a negative MVP result is not failure. It's the cheapest thing that could happen. You spent 2-6 weeks learning something that would have taken 6-18 months to learn post-launch.

The MVP is not the product

This is the part most founders forget.

The MVP's job is not to be your product. Its job is to generate enough evidence to justify building the next version — or to tell you clearly not to.

If your MVP gives you signal, the next step is not "build the full product." It's: run the next experiment. Answer the next question. Validate the next assumption.

You build your way to a real product by running validated experiments, not by shipping a roadmap.

The best founders don't build better first products. They run better experiments, faster, with smaller bets.

Validate your idea before you build →