Decisions

Should you build an MVP or validate first?

The honest default is: validate first. An MVP is still a build, and building before you have evidence is the most expensive way to learn you were wrong.

Guide · 5 min read

"MVP" and "validation" are not the same step. Validation answers should this exist. An MVP answers can we deliver and operate it. Doing them in the wrong order burns months and budget.

Validate first when…

• You are not yet sure people will change behavior to use it.
• The idea is unproven in your specific market or audience.
• Budget is tight and a wrong build would hurt.
• You are mainly testing whether one core workflow lands.

Build the MVP when…

• You already have evidence of demand (waitlist, paying pilots, repeat manual use).
• The risk is now execution and operations, not desirability.
• You need real accounts, payments, or data to deliver the value at all.

The cheap bridge between them

Between a conversation and a full MVP sits the clickable prototype. It lets real users complete the core workflow so you observe behavior, not opinions — the difference explained in clickable prototype vs. mockup. It is cheap enough to run before you commit to the cost of an MVP, which is why an MVP prototype should not be priced like a production build.

Rule of thumb: if you cannot name the evidence that would make you not build, you are not ready to build. Validate first.

A simple sequence

1. Talk to ten people with the problem.
2. Run a cheap test for real interest.
3. Build a clickable prototype and watch people use it.
4. Only then invest in the MVP.

← Back to Promptlaiy