Prototype, MVP or product? How to validate an idea before investing

Many product projects start at the end: they build the solution before knowing whether the problem exists, who has it and how much they're willing to pay to solve it. By the time the answer arrives, the budget is already spent.

A prototype, an MVP and a product answer different questions. Mixing them up means paying to answer the wrong question. This guide shows what to build at each stage, a four-week schedule to validate an idea and the signs that tell you whether to move forward or stop.

The problem first, then the solution

Before deciding what to build, validate the problem and the process around it. Who has this problem? How do they solve it today: with which tools, which steps, how much time wasted? What does it cost them not to solve it?

These answers tell you whether there's a problem worth solving and show where the solution has to fit. A solution designed without understanding the customer's process solves a problem nobody has, or solves the right one the wrong way.

Write down the hypothesis

Before writing a single line of code, complete this sentence:

"I believe that [type of customer] will pay [amount] for [solution] because [problem]."

If you can't fill in every blank, you're not ready to build yet. And decide now what counts as success and what counts as failure: what answer, from how many people, would make you move forward or stop.

Prototype, MVP or product: what to build at each stage

Prototype

• The question it answers: "do people understand this and want it?"
• What it has: clickable screens, a presentation page, a short video showing the idea.
• What it doesn't have: a real backend, authentication, payments.

MVP

• The question it answers: "will anyone use this and pay for it?"
• What it has: the main flow working for real, with only the features that prove the value. Behind the scenes, part of the work can be done by hand.
• What it doesn't have: anything that isn't needed to answer the question.

Product

• The question it answers: "how do I serve this to many customers reliably?"
• What it has: robustness, security, performance, tests, monitoring and support.
• When: only after the MVP shows a clear sign of demand.

What an MVP is (and isn't)

MVP stands for Minimum Viable Product, and all three words count:

• Minimum: as little as possible to answer a question.
• Viable: it really works; it isn't a mock-up.
• Product: someone can use it and pay for it.

These are not MVPs:

• an "interactive" Figma with no backend;
• a "coming soon" page with a waiting list;
• a "beta" that takes months to come out.

These things have value, but they validate interest, not a product. They belong to the prototype stage.

A four-week schedule to validate

Four weeks is a working pace, not a promise: the goal is to reach an answer, not a finished product.

Week 1: interviews. Talk to potential customers about the problem and how they solve it today. No demos, just questions. Keep going until you start hearing the same answers. Look for patterns, not compliments.

Week 2: prototype. Screens, a presentation page and a short video. Still no real code.

Week 3: pre-sale or equivalent. Show the prototype to people who fit the profile and ask for a concrete commitment: an advance payment, a paid pilot, a letter of intent or a meeting with the decision-maker. A yes with a commitment is worth more than plenty of compliments.

Week 4: minimal build. Only the flow that the people who committed need. Doing part of the work by hand behind the scenes is fine at this stage. The goal is to deliver to the first customer.

Signs to move forward and signs to stop

You're on the right track when:

• customers are willing to pay before the product exists;
• they ask for specific features, not generic ones;
• they complain when something breaks, because they already depend on it.

It's time to stop or change course when:

• almost everyone's answer is "interesting, but…";
• they ask for a discount before they've seen any value;
• nobody recommends the solution to anyone else.

Stopping is also a result. Finding out in four weeks that the idea doesn't take off costs far less than finding out after building the product.

The MVPs that fail (and why)

• Too complete. The urge to "do it properly" delays the launch until the market has already moved on.
• Built before understanding the process. The solution doesn't fit the way the customer works, and nobody adopts it.
• No distribution plan. It was built, it was launched and nobody heard about it. Getting the MVP to the right people is part of the MVP.
• No success and failure criteria. "If it goes well, we'll carry on" isn't a criterion. Decide before you build what counts as a signal to move forward.

Conclusion

Building in the right order isn't slow. It's the fastest way to get to something that works: first the problem and the process, then the prototype, then the MVP and only at the end the product. At each stage, build only what you need to answer that stage's question.

Frequently asked questions

What's the difference between a prototype and an MVP?

A prototype tests whether people understand and want the idea, with no real backend. An MVP tests whether anyone will use it and pay for it, with the main flow working for real.

How long does it take to validate an idea?

It depends on the problem and on access to customers. The four-week schedule in this article is a reference for pace: interviews, prototype, pre-sale and minimal build.

Can an MVP have manual processes behind it?

Yes. At this stage, doing part of the work by hand behind the scenes is a cheap way to test the value before automating.

When should I move from MVP to product?

When the MVP shows a clear sign of demand: customers who pay, who keep using it and who recommend the solution.