From Idea to MVP: What to Validate Before You Build

An MVP is an experiment, not a cheap product

The test of an MVP is not whether it is small. It is whether a negative result would change your mind. If you would build the full thing regardless of what happens, you are not validating anything — you are just shipping late.

Write down, before anything is built, what result would make you stop. Teams that skip this step rarely stop.

Validate the three things that actually kill products

• The problem: do people already spend money, time or effort on this?
• The willingness: will they pay, and at roughly what price?
• The channel: can you reach them repeatedly without burning cash?

The third kills more startups than the first two combined, and it is the one almost nobody tests before building.

What you can learn without writing code

Thirty conversations with people in the market will reshape the scope more than any amount of engineering. A landing page with a real price and a waitlist tests willingness. A manual version — you doing the work by hand for five customers — tests whether the output is even wanted.

Each of those costs days. The build costs months.

Scope the MVP down to one complete journey

Signup to the moment of value, finished and working. Not two features half-built. A half-built second feature teaches you nothing, because users cannot tell you whether they would have liked it.

Everything else — settings, admin polish, the second user role, the integrations — waits for evidence.

Instrument it before you launch it

You cannot learn from an MVP you cannot measure. Activation, retention at day seven, and the point where people drop out. Three numbers, in place before the first user arrives.

If the MVP fails, it did its job for a fraction of what a full build would have cost. That is the whole point of the format.