Validate Before You Build: Why Startups Need an MVP

Before Canva became a design platform used across the world, it was a yearbook design tool. Melanie Perkins and Cliff Obrecht believed design software was too hard for ordinary people, so they tested that belief with Fusion Books, a small product that let Australian schools build their own yearbooks. Real schools paid, real students used it, and the founders learned precisely why. Canva’s founding story rests on that unglamorous validation.

Canva itself launched in August 2013 to a waiting list of more than 50,000 people and drew about 500 visitors on day one, roughly 5,000 within a week, and around 20,000 within a month. That is what a minimum viable product looks like in practice: the smallest, honest experiment that puts real value in front of the right people to answer the one question that could kill the company.

What an MVP actually is in practice

A minimum viable product is the smallest, honest experiment that puts real value in front of the right people to answer the riskiest question about your business. Notice which word carries the weight. Minimum describes the scope. Viable describes the standard. Founders tend to hear the first word and skip the second, which is how the industry filled up with half-built apps that taught their makers nothing.

Eric Ries, author of The Lean Startup, defined an MVP as the version of a product that yields “the maximum amount of validated learning about customers with the least effort.” Even in the canonical definition, the center of gravity sits on validated learning.

This reading resolves a contradiction that trips up many teams. An MVP still has to do its one essential job reliably, yet a landing page with nothing built behind it can be a legitimate MVP. Both statements hold because the reliability standard attaches to the experiment rather than to a finished product. A landing page’s essential job is to produce an honest signal. If it truthfully represents the offer and captures real intent, it does that job reliably. If it overpromises or counts idle clicks as demand, it fails, however little it cost.

Minimum, but viable

Here is the crux. The standard an MVP must meet is an honest signal, a yes or a no you can trust. The most common failure is an MVP that hits minimum and misses viable, too thin to earn either. If the test delivers so little value that even people with the problem walk away, a no tells you nothing about demand. It only tells you the experiment was broken.

The familiar MVP formats are best understood as ways to fake the product cheaply so you can test the risk. Each carries its own bar for honesty.

• Landing page. A page that describes the product as if it exists and asks for a commitment. Viable means it truthfully represents what you will build and captures intent strong enough to mean something, an email at minimum, a preorder if you can.
• Concierge. You deliver the outcome manually for a handful of customers, no software at all. Viable means the customer receives a real result, so you learn whether that result is worth paying for.
• Single-feature product. Real software that does exactly one job. Viable means that job works completely and reliably for the person who needs it.
• Prototype. A clickable or physical mockup placed in users’ hands. Viable means the tasks are realistic and you measure what people do rather than what they politely say.

Put it in front of the right people

A clean experiment run on the wrong sample still returns a wrong answer. The signal from an MVP is only as strong as the audience it comes from, and that audience is a hand-picked group of early adopters and design partners who feel the pain sharply enough to tolerate rough edges, people you can name individually and call afterward. Melanie Perkins described Canva’s early method: “We’d speak to our customers, learn what they wanted, then iterate on it.”

Consumer brands follow the same logic. Companies like HeyTea and Chi Forest each earned devotion from a narrow, shareable early niche before the mass market heard of them. The right hundred people generate a truer signal than a random hundred thousand.

Run it like an experiment

An MVP without an experimental design is just a small launch. Five steps keep it honest.

1. Name the assumption and the success threshold

Before building anything, write down the killer assumption and the result that would count as validation, for instance, four of ten pilot users convert to paid. Setting the bar after the data arrives is how teams talk themselves into anything.

2. Pick the cheapest honest test

Choose the least effort that still clears the viability bar. If a concierge run can answer the question, do not write code.

3. Choose the specific audience

List the actual people or companies who feel the problem most acutely. Write down names.

4. Ship fast and instrument the one action that matters

Give it weeks. Measure the single behavior tied to the assumption and resist adding anything that does not serve it.

5. Measure behavior and honor the decision you set in advance

Count what people did: paid, returned, referred. Decide before the data arrives which result means scale, which means iterate, and which means kill.

Traps that turn an MVP into wasted motion

• Minimum but not viable. The version is too thin to deliver real value, so no result can be trusted.
• Testing with the wrong audience. Friends, family, and casual browsers produce comfortable noise.
• Trusting words over behavior. People say yes to be kind. Payment, return visits, and referrals do not lie.
• Building when you could fake it. Webvan sank more than 800 million dollars into automated warehouses before validating demand, then collapsed.
• No pre-committed decision rule. Without a threshold set in advance, every result gets reinterpreted as encouragement.
• Perfectionism. Every month of polish is a month the killer assumption goes untested.
• Falling in love with the solution. The experiment quietly becomes a defense of the product instead of a test of it.

The bottom line

Minimum in scope, viable in value. An MVP is an honest signal from the right audience, judged against a decision you set before the data came in. It is scoped by the one assumption that could kill the company, and it can be a landing page, a manual service, or a single feature, as long as the signal it produces can be trusted. A clear startup vision tells you where you are ultimately going. The MVP tells you whether the world agrees about the first step.

Frequently Asked Questions

What is the difference between an MVP and a prototype?

A prototype tests whether something can be built and understood. An MVP tests whether anyone wants it by putting real value in front of real users and measuring behavior.

How long should an MVP take to build?

Weeks in many cases, sometimes days. With AI and no-code tools, the engineering is becoming less of a restraint than it was only a couple of years ago. A build that stretches past a couple of months has usually drifted toward building the whole product.

How many users do I need for a trustworthy signal?

Fewer than most founders expect, provided they are the right users. A dozen design partners who feel the pain acutely will teach you more than a thousand random visitors, because depth of engagement matters more than sample size at this stage.

What should I do if my MVP fails the test?

Treat a clean no as the experiment succeeding, because it saved the runway you would have spent building. Return to the decision rule you set in advance. Iterate if the signal points to a fixable flaw, and move on if the core assumption itself collapsed.

How polished does an MVP need to be?

Polished enough that roughness does not corrupt the signal. Early adopters forgive an ugly interface, but they don’t forgive broken value. The one job the experiment performs must work reliably.