Validation landing page vs prototype vs MVP: a decision framework

Founders often ask the wrong question: “What can we build fastest?” The better question is “What evidence do we need next, and what is the cheapest surface to get it?” A validation landing page, a clickable prototype, and a thin MVP each produce different types of evidence. Picking the wrong one wastes time or gives false confidence.

This framework helps you choose deliberately, not by habit.

The evidence ladder (and why it matters)

Validation is not one step; it is a ladder. Each rung increases the strength of evidence and the cost to obtain it.

1. Problem evidence: people recognize the problem and can confirm frequency/pain.
2. Demand evidence: people are willing to take a small action (email, call, calendar).
3. Solution evidence: people prefer your approach and believe it could work.
4. Usage evidence: people actually use it when it is available.
5. Retention evidence: people keep using it over time.

A landing page is great at rungs 1–2. A clickable prototype reaches rung 3. An MVP gets you to rungs 4–5. Build the smallest thing that can get you to the next rung.

A simple decision matrix

Use four questions to decide between a landing page, a prototype, and an MVP.

1) What type of decision do you need next?

• If you need to validate the problem or willingness to talk, a landing page is enough.
• If you need to validate the workflow or mental model, a prototype is the right next step.
• If you need to validate actual usage or data flow, you need an MVP.

Landing pages are about messaging. Prototypes are about interaction. MVPs are about real behavior.

2) How falsifiable is your hypothesis?

If a “no” result is hard to interpret, you should not spend engineering time.

• Landing page: best for hypotheses like “Founders who run paid pilots will request a call.”
• Prototype: best for “Users understand the flow without guidance.”
• MVP: best for “Teams will return weekly to update their pipeline.”

The stronger your falsifiability, the smaller the surface you need.

3) How costly is the wrong answer?

If a wrong answer puts you months off course, move one rung up. For example, a landing page can validate demand for a B2B workflow, but if the workflow is complex, a prototype might be necessary before committing to a pricing model.

4) How much operational overhead can you afford?

Landing pages are cheap to iterate and have almost zero operational cost. Prototypes are heavier to create but still low-maintenance. MVPs create data, support, and uptime expectations. The overhead itself can distort results if it slows your iteration cycle. (This is the core argument in “Validation landing pages shouldn’t be overhead”.)

When a validation landing page is the right move

Choose a landing page when your uncertainty is primarily positioning or target segment. It is also ideal if you are still testing different problem statements.

A landing page gives you:

• A clean signal on messaging and objections.
• A way to run founder-led outreach with a credible surface.
• A repeatable asset you can reuse across tests.

If you need to decide between build paths or target customers, a landing page is the cheapest way to compare.

If you are unsure which tool to build it with, see the comparison in “Astro vs Framer/Webflow for MVP validation landing pages”.

When a clickable prototype is the right move

Prototypes are best when you need interaction evidence but not real data. They answer questions like:

• “Will users find this feature without a walkthrough?”
• “Does the order of steps make sense?”
• “Does this pricing model feel fair when attached to a workflow?”

A prototype is also useful when your landing page converts well but calls reveal confusion about how the product actually works. If your problem is understood but the solution is unclear, move to a prototype before writing production code.

When a thin MVP is justified

Build a thin MVP when the central risk is behavioral. Examples:

• A usage pattern must repeat weekly to be viable.
• A workflow depends on real data from integrations.
• Value only appears after the second or third session.

A thin MVP should still be very small, but it must be real. Fake buttons can mislead here. If you need to measure retention, you need a working product surface.

Three practical heuristics

The “minimum believable artifact” rule

Build the smallest thing that a skeptical user would consider real. For some markets, that is just a landing page. For others (e.g., compliance or finance), it might require a working flow.

The “conversation to usage ratio” rule

If you can get 10 high-quality conversations from a landing page within a week, keep it. If conversations stall because people need to see the product, move to a prototype.

The “time-to-evidence” rule

If a prototype buys you evidence in 2–3 days, use it. If it takes two weeks, it might be slower than running more landing page tests.

Example decisions in practice

• B2B analytics tool: Start with a landing page to validate segment and pain. Move to a prototype once you see consistent inbound interest.
• Consumer habit app: Landing page alone is weak. A prototype to test onboarding flow is more valuable before building.
• Operations tool with integrations: Landing page for initial demand, then a thin MVP because the integration is the core risk.

The short version

Use a landing page to test messaging and intent, a prototype to test workflows, and an MVP to test real behavior. The mistake is not choosing one, it is choosing the wrong rung for the evidence you need next.

Interested? Write me. /#kontakt