5 Validation MVP Formats: What to Build Before a Full MVP
Not every early product artifact should be called an MVP.
Founders use the word MVP for almost everything: a landing page, a demo, a prototype, a no-code workflow, a full product with fewer features, or a first version of a SaaS platform. That creates confusion because each artifact answers a different question.
A validation MVP has a narrower job.
It is not the smallest product you can launch. It is the smallest artifact that can create credible evidence for the decision in front of you.
Sometimes that means no software. Sometimes it means a prototype. Sometimes it means a real but narrow product. The right format depends on the riskiest assumption.
That is the editor’s rule for this article: do not choose a build format by taste. Choose it by risk.
Here are five validation MVP formats and when to use each one.
Quick Answer: What Is A Validation MVP?
A validation MVP is a deliberately limited product, prototype, workflow, or test artifact built to validate a specific assumption before a larger product investment. Unlike a full MVP, a validation MVP is judged by learning quality, not feature completeness.
The goal is to answer one of these questions:
- Does the problem matter enough?
- Will users take action?
- Can the workflow create value?
- Will buyers pay?
- Does the product need to exist at all?
If the artifact does not produce a clearer decision, it is not a validation MVP. It is just a small build.
Format 1: Concierge MVP
A concierge MVP delivers the value manually before the product is automated.
Instead of building the full software system, the team performs the service behind the scenes and observes whether the user actually wants the outcome.
Best For
- Workflow-heavy products
- AI products where automation risk is high
- Services that may become software
- B2B products with complex user behavior
- Ideas where the value is clearer than the interface
Example
Instead of building an AI sales assistant, the team manually reviews inbound leads, scores them, drafts follow-up recommendations, and routes the best ones to sales. Users experience the outcome before the automation exists.
What It Tests
- Is the outcome valuable?
- How does the workflow really happen?
- What edge cases appear?
- What would users trust or reject?
- Which steps should be automated later?
What It Does Not Test
A concierge MVP does not prove that software can scale cheaply. It proves whether the outcome deserves automation.
Good Signal
Users come back, ask for repeat delivery, give access to real inputs, or pay for the manually delivered result.
Bad Signal
Users say the output is interesting but do not change behavior, share real data, or ask for it again.
Format 2: Fake-Door MVP
A fake-door MVP tests demand for a product, feature, or offer before it exists.
The user sees a real call to action: “Join waitlist”, “Request access”, “Start trial”, “Book demo”, “Add integration”, or “Upgrade”. After clicking, the team explains that the feature is coming soon or routes the user into a research flow.
Best For
- Testing feature demand
- Comparing value propositions
- Measuring channel response
- Prioritizing roadmap bets
- Finding high-intent segments
Example
A SaaS team adds a “Generate investor proof memo” button inside a founder dashboard. Before building the full feature, they measure who clicks, from which segment, and what they expect the output to do.
What It Tests
- Does the promise create action?
- Which segment wants it most?
- Which message performs best?
- What level of intent exists before delivery?
What It Does Not Test
It does not prove retention, workflow quality, or willingness to pay unless paired with deeper follow-up.
Good Signal
Qualified users click, answer follow-up questions, book calls, or ask when they can use the product.
Bad Signal
Clicks are high but follow-through is weak, or the wrong audience responds.
Format 3: Clickable Prototype
A clickable prototype simulates the product experience without building the underlying system.
It can be made in Figma, Framer, a lightweight frontend, or another prototyping tool. The point is to test comprehension, workflow, and perceived value before engineering investment.
Best For
- UX-heavy products
- Investor or stakeholder demos
- Complex workflows
- Products where users need something visual
- Early sales conversations
Example
A team validating a marketplace creates a clickable flow for buyers and suppliers. The prototype shows onboarding, matching, messaging, and transaction steps without building marketplace infrastructure.
What It Tests
- Do users understand the concept?
- Does the flow match their mental model?
- Which steps create confusion?
- What information do users need before trusting it?
- Does the product story feel credible?
What It Does Not Test
It does not prove demand by itself. A prototype can impress users who still never pay, switch, or adopt.
Good Signal
Users describe how they would use it in their real workflow, point out missing constraints, ask about pricing, or introduce other stakeholders.
Bad Signal
Users praise the design but cannot name a concrete use case or next step.
Format 4: Workflow MVP
A workflow MVP is a narrow product surface that fits into one real operational process.
It is more functional than a prototype and less complete than a full product. It usually handles one repeatable workflow end to end.
Best For
- AI workflow tools
- Internal products
- Ops automation
- B2B productivity products
- Products where adoption matters more than signups
Example
Instead of building a full legal operations platform, a team builds one intake review workflow: upload documents, extract fields, flag exceptions, route to human review, and measure time saved.
What It Tests
- Does the tool fit real work?
- Do users trust the output?
- Does it save time or improve quality?
- What human review is required?
- What data or integration gaps matter?
What It Does Not Test
It may not prove broad platform demand. It proves whether one workflow can carry value.
Good Signal
Users use it repeatedly, ask for it inside their actual process, and can quantify time saved, error reduction, faster response, or better throughput.
Bad Signal
The tool works technically but sits outside the real workflow, requires too much cleanup, or creates more review burden than value.
Format 5: Narrow Paid V1
A narrow paid V1 is the first real product version sold to a sharply defined segment.
It is not a broad MVP with half-built features. It is a complete product slice for a small, valuable use case.
Best For
- Products with enough validation to justify build
- B2B SaaS wedge products
- Paid pilots
- Founder-led sales
- Narrow vertical software
Example
Instead of building a full CRM product for investors, a team builds one paid workflow for angel syndicates: collect founder materials, score evidence quality, generate diligence notes, and track follow-up.
What It Tests
- Will a real buyer pay?
- Can the product deliver repeatable value?
- Is the wedge strong enough to expand?
- What support is needed for adoption?
- What pricing and packaging works?
What It Does Not Test
It does not prove that the entire roadmap should be built. It proves whether a focused wedge deserves continuation.
Good Signal
Paid use, repeated use, expansion requests, referrals, or conversion from pilot to ongoing contract.
Bad Signal
Buyers like the idea but only want custom work, discounts, or unpaid pilots with no conversion path.
How To Choose The Right Validation MVP
Use the riskiest assumption to choose the format.
| Risk | Best Format |
|---|---|
| Unsure whether the outcome matters | Concierge MVP |
| Unsure whether people will click or request it | Fake-door MVP |
| Unsure whether users understand the experience | Clickable prototype |
| Unsure whether it fits a real process | Workflow MVP |
| Unsure whether buyers will pay for a narrow wedge | Narrow paid V1 |
The worst choice is building a full MVP when the unanswered question could be tested with a smaller artifact.
Decision Tree
Use this simple decision tree before you scope the build:
- If the team does not know whether the outcome matters, run a concierge MVP.
- If the team does not know whether the promise creates action, run a fake-door MVP.
- If the team does not know whether users understand the flow, build a clickable prototype.
- If the team does not know whether the product fits real work, build a workflow MVP.
- If the team does not know whether buyers will pay, build a narrow paid V1.
Do not skip to step 5 because it feels more impressive. A narrow paid V1 is only useful after the earlier uncertainties are low enough.
The 30-Minute Selection Exercise
Write these three sentences before choosing the format:
- The riskiest assumption is:
[assumption]. - The evidence that would change our next move is:
[behavior, payment, adoption, usage, or buyer signal]. - The smallest artifact that can create that evidence is:
[format].
If the third sentence says “full MVP”, challenge it. Most full MVPs are carrying several unanswered questions at once.
The discipline is to answer one question at a time. A validation MVP that tries to prove demand, usability, pricing, retention, and scalability in one move usually becomes a full product by accident.
Validation MVP vs Prototype vs Full MVP
| Artifact | Main Question | Success Metric |
|---|---|---|
| Prototype | Do users understand it? | Clarity, workflow feedback, stakeholder response |
| Validation MVP | Does this assumption deserve more investment? | Behavioral, commercial, or adoption evidence |
| Full MVP | Can a first version deliver real product value? | Usage, retention, revenue, learning velocity |
Founders often skip the validation MVP and jump from prototype to full build. That is where overbuilding begins.
FAQ
Should a validation MVP be paid?
Not always. But if willingness to pay is the riskiest assumption, the validation MVP should include a payment, deposit, paid pilot, LOI, or clear commercial commitment.
Can a landing page be a validation MVP?
Yes, if the decision is about message, segment, demand, or channel. No, if the decision is about retention, workflow adoption, or whether the product can deliver value.
How long should a validation MVP take?
Usually days to a few weeks. If it takes months, it is probably a full build pretending to be validation.
What You Now Know
A validation MVP is not a smaller product. It is a question-answering artifact.
The format should be chosen by the risk: value, demand, comprehension, workflow adoption, or payment.
What To Do Next
Name your riskiest assumption. Choose exactly one validation MVP format. Define the signal that would justify a full build.
If you cannot name the signal, do not scope the build yet.
When To Bring In Proof Engine
Bring in Proof Engine when the team is about to spend real product budget but is not sure whether to run a concierge MVP, fake-door test, prototype, workflow MVP, or narrow paid V1.
The right first artifact can save months of building the wrong one.