Types of MVPs: Choose the Right Approach (Decision Tree + Cost Guide 2026)
"Build an MVP" means something different depending on what risk you're trying to reduce. This guide covers eight distinct MVP types—from landing pages to Wizard of Oz experiments—with a decision tree to help you choose the one that answers your riskiest question with the least effort.
Many founders hear “build an MVP” and immediately think: build a smaller product. Sometimes that’s right. Often, it isn’t.
At MVP stage, your goal is a clear signal. Different MVP types exist because different risks exist.
If you’re still deciding what artifact you need, start with MVP vs Prototype vs PoC.
The best MVP is the one that answers your question
Before picking a type, define the question:
- Do users want this outcome?
- Will they trust this process?
- Will they pay?
- Can we deliver reliably?
Your MVP type follows from the question, not the other way around.
For more on scoping once you’ve chosen your type, see our guide on how to scope an MVP.
Decision tree: which MVP type to choose?
Answer these 6 questions to find your MVP type:
Question 1: Do you have confirmed demand?
- Yes (5+ people asked you to build this, or you have manual clients) → Skip to Q2
- No (idea stage, no validation) → Landing Page MVP (validate demand first)
Question 2: Do you know exactly what users need?
- Yes (clear requirements, you’ve delivered manually before) → Skip to Q3
- No (unsure which features matter most) → Concierge MVP (learn by delivering manually)
Question 3: Is the hard part delivery or demand?
- Demand (you can deliver, but unsure if anyone wants it) → Landing Page + Pre-order
- Delivery (people want it, but complex to build) → Skip to Q4
Question 4: Can you fake automation temporarily?
- Yes (manual processing feasible for 10-50 users) → Wizard of Oz MVP
- No (real-time required, or safety-critical) → Skip to Q5
Question 5: Is there ONE feature that drives all value?
- Yes (users buy for single reason, rest is nice-to-have) → Single-Feature MVP
- No (multiple features create value together) → Skip to Q6
Question 6: Do you need to test willingness to pay ASAP?
- Yes (pricing unclear, need revenue signal) → Paid Pilot MVP
- No (pricing clear, focus on usage first) → Full MVP (4-8 week build)
For execution planning once you’ve chosen, see our MVP roadmap: 4-8 weeks.
Decision tree visualization
Common MVP types with real examples
Landing page MVP
Best for: Positioning and demand clarity.
How it works: Single page describing the product, with CTA (waitlist, demo request, quote request).
Real example (anonymized):
A founder testing “AI-powered sales lead enrichment” created a landing page with:
- Hero: “Enrich 500 leads in 15 minutes, not 3 hours”
- 3 benefits (accuracy, speed, integrations)
- Pricing tiers (not built yet)
- Waitlist CTA
Result: 127 signups in 2 weeks via LinkedIn outreach. Validated demand before writing code.
Timeline: 1-3 days
Cost: €500-€2k (Webflow + copywriter if outsourced), €0 if DIY
Meaningful actions:
- Waitlist signup (low commitment, 5-10% convert to users typically)
- Demo request (medium commitment, 20-30% convert)
- Pre-order with deposit (high commitment, 60-80% convert—see pricing validation)
When to use:
- You’re unsure if anyone wants this
- Positioning is unclear (multiple value props to test)
- Zero budget for development
When NOT to use:
- You already have demand signals (5+ requests, manual clients)
- The hard part is delivery, not demand
Concierge MVP
Best for: Learning real needs quickly by delivering outcomes manually.
How it works: You personally deliver the service to 5-10 customers, observing what they actually need (not what they say they need).
Real example:
Booking automation tool founder manually booked client meetings for 2 weeks:
- Learned clients cared more about rescheduling than initial booking
- Discovered calendar integrations were critical (not on original roadmap)
- Found pricing sweet spot through direct conversations
Result: Pivoted feature priority before building anything. Saved 6 weeks.
Timeline: 2-4 weeks (delivery phase)
Cost: €0 (time-intensive, but no build cost), charge clients €500-€2k to cover time
When to use:
- You don’t know which features matter most
- Service-oriented products (not pure software)
- Complex workflows where user needs are unclear
When NOT to use:
- Product requires real-time automation (manual delivery impossible)
- You already know exact requirements from previous experience
How to price: Charge for concierge MVP. Even at cost or slight loss, payment = validation.
Wizard of Oz MVP
Best for: Validating experience before automation (manual behind the scenes).
How it works: Users interact with what looks like automated software, but you’re manually processing actions behind the curtain.
Real example:
AI resume screening tool showed “AI analysis” results in 2 minutes. Reality: Founder manually reviewed resumes and sent results via backend script.
Result: Validated users trusted AI recommendations. Built real ML model after 50 paid users.
Timeline: 3-6 weeks (build fake automation UI + manual process)
Cost: €5k-€15k (simple UI + manual workflow backend)
Ethical boundaries:
- OK: Manual data processing, delayed automation, human-in-loop for non-critical features
- NOT OK: Claiming automation for safety-critical features (medical diagnosis, financial advice), fake testimonials, misleading about data handling
When to use:
- Automation is expensive/complex but UX is testable
- You want to validate user trust before investing in ML/AI
- Service can be delivered manually without quality loss
When NOT to use:
- Real-time requirements (manual processing too slow)
- Safety/compliance critical (manual = liability)
Single-feature MVP
Best for: When one interaction drives most value.
How it works: Build only the core feature, skip everything else.
Real example:
Project management tool launched with only “task dependencies” feature. No time tracking, no reporting, no integrations.
Result: 40% of signups became paying customers because dependencies solved critical pain. Added other features after validation.
Timeline: 4-8 weeks
Cost: €8k-€25k (depending on technical complexity)
Feature selection rule: If you remove this feature, does the product still solve the core problem? If no, it’s your single feature.
When to use:
- Clear core value (users buy for one reason)
- Competitive landscape full of bloated products
- Technical risk is low, product-market fit risk is high
When NOT to use:
- Multiple features create value together (marketplace = supply + demand)
- Single feature isn’t usable alone (payment without checkout flow)
Prototype-to-MVP bridge
Best for: When UX risk is high.
How it works:
- Prototype phase: Figma mockups + user testing (1-2 weeks)
- MVP phase: Build functional version of validated UX (4-6 weeks)
Real example:
Healthcare appointment scheduling tested 3 UX approaches via Figma:
- Calendar view (won: 80% user comprehension)
- List view (70% comprehension)
- Chatbot interface (40% comprehension, users confused)
Result: Calendar view won in user tests. MVP built only calendar version. Saved 4 weeks vs building all 3.
Timeline: 6-8 weeks total (prototype 1-2w + MVP 4-6w)
Cost: €2k (prototype) + €8k-€15k (MVP) = €10k-€17k total
When to use:
- Complex workflows (multi-step, conditional logic)
- Novel interactions (users haven’t seen this pattern before)
- High drop-off risk (onboarding, checkout flows)
When NOT to use:
- Standard UX patterns (login, CRUD forms)
- You’ve built similar products before
Paid pilot / pre-order MVP
Best for: Testing willingness to pay early.
How it works: Sell the product before building it (or with limited functionality).
Real example:
B2B analytics tool offered “6-week paid pilot” for half the future price:
- 10 companies signed up
- 7 completed pilot
- 6 converted to annual contracts
Result: Revenue before launch + validation of pricing.
Timeline: 4-8 weeks (pilot delivery)
Cost: €0-€5k (depends if you deliver manually or with minimal tool)
See full playbook in pricing validation.
When to use:
- B2B products (pilots are common)
- High-consideration purchases (users research before buying)
- Unclear pricing (need real willingness-to-pay data)
When NOT to use:
- Impulse purchases (low price, instant decision)
- Regulated industries where pre-selling is restricted
Cost and timeline comparison table
| MVP Type | Timeline | Cost (DIY) | Cost (Outsourced) | Signal Strength | Risk Reduced |
|---|---|---|---|---|---|
| Landing page | 1-3 days | €0 | €500-€2k | Low-High (depends on CTA) | Demand |
| Concierge | 2-4 weeks | €0 (time only) | N/A | Very High | Real needs |
| Wizard of Oz | 3-6 weeks | €2k-€5k | €5k-€15k | High | Experience/trust |
| Single-feature | 4-8 weeks | €0-€5k (if technical) | €8k-€25k | High | Core value |
| Prototype + MVP | 6-8 weeks | €2k-€5k | €10k-€17k | Very High | UX + product |
| Paid pilot | 4-8 weeks | €0-€2k | €5k-€15k | Very High | Willingness to pay |
| Full MVP | 6-10 weeks | €5k-€10k | €15k-€35k | Very High | All risks |
Cost assumptions: Outsourced = €50/hour dev rate, design included. DIY = founder has technical skills.
Hybrid approaches: combining MVP types
Sometimes one type isn’t enough. Common combinations:
Landing page + Concierge
Flow:
- Landing page validates demand (week 1-2)
- Concierge MVP delivers to first 10 signups (week 3-6)
Why it works: Landing page = cheap demand test. Concierge = deep learning on real users.
Cost: €500 (landing page) + €0 (concierge time) = €500 total
Timeline: 6-8 weeks
Wizard of Oz + Paid pilot
Flow:
- Build fake automation UI (week 1-4)
- Deliver manually to paid pilots (week 5-8)
Why it works: Paid pilots = willingness to pay. Wizard of Oz = experience validation before expensive automation.
Cost: €5k-€10k (Wizard UI) + €0 (pilot delivery) = €5k-€10k
Timeline: 8 weeks
Prototype + Single-feature MVP
Flow:
- Prototype 3 UX variations (week 1-2)
- Build winning UX with only core feature (week 3-8)
Why it works: De-risks both UX and feature scope.
Cost: €2k (prototype) + €8k-€15k (single-feature) = €10k-€17k
Timeline: 8 weeks
Common mistakes when choosing MVP type
Mistake 1: Building software when demand is the risk
Symptom: “Let’s build a beta version and see if anyone signs up.”
Why it fails: 8 weeks building + $0 signups = wasted time.
Fix: Start with landing page + outreach. If no one clicks “Request Demo,” don’t build the demo.
Mistake 2: Doing landing page when delivery is the hard part
Symptom: 500 waitlist signups, but you have no idea how to deliver.
Why it fails: Demand validated, but can’t convert to users because delivery broken.
Fix: If you know people want this (existing manual clients, clear demand), use concierge to learn how to deliver.
Mistake 3: Avoiding payment tests
Symptom: “Let’s get users first, monetize later.”
Why it fails: Free users give false signals. 1,000 free users ≠ 10 paying users.
Fix: It feels uncomfortable to charge for an unfinished product. But free users give false signals.
Rule: If you wouldn’t pay for it, why would they?
Mistake 4: Combining too many approaches
Symptom: Landing page + concierge + Wizard of Oz + prototype = 12 weeks, no clear signal.
Why it fails: Analysis paralysis. Each type tests different risk—combining all = confusion.
Fix: Pick 1-2 max based on highest risk. Ship, learn, decide next.
Mistake 5: Choosing type based on what you CAN build, not what you NEED to learn
Symptom: “I’m a developer, so I’ll build a full MVP” (even though demand is the risk).
Why it fails: Playing to strengths ignores actual risk.
Fix: Choose MVP type based on biggest unknown, not your skillset.
Failure case studies (what NOT to do)
Case 1: Full MVP when landing page would suffice
Scenario: Founder spent 10 weeks building “AI meal planner” MVP. Launched, got 12 signups, 2 activations.
What went wrong: Never validated demand. Built because “seemed like a good idea.”
Should have done: Landing page (€500, 3 days) with “Join waitlist for meal plans.” If <100 signups in 2 weeks via ads, idea weak.
Cost of mistake: 10 weeks + €15k wasted vs €500 + 3 days to invalidate.
Case 2: Landing page when concierge needed
Scenario: B2B sales tool got 200 waitlist signups. Built MVP based on assumptions. Launched, 30% activated, 5% returned.
What went wrong: Assumed they knew what users needed. Built wrong features.
Should have done: Concierge MVP with first 10 waitlist signups (manually deliver sales research for 2 weeks, learn real workflow).
Cost of mistake: 8 weeks building wrong features + 6 weeks rebuilding = 14 weeks vs 6 weeks (2w concierge + 4w correct MVP).
Case 3: Free users when pricing was the risk
Scenario: SaaS tool launched free tier, got 500 users. Introduced €29/month pricing 3 months later, 8 converted (1.6%).
What went wrong: Free users ≠ paying users. Attracted wrong audience.
Should have done: Paid pilot from Day 1 (€15/month discounted). 50 paid users > 500 free users for validation.
Cost of mistake: 3 months supporting free users + false confidence in product-market fit.
Choose the type based on dominant risk
Conclusion
There is no single correct MVP type. Choose the one that produces a clear signal with the least cost.
Remember:
- Decision tree: 6 questions (demand? needs? delivery? automation? one feature? pricing?) → MVP type
- Cost range: Landing page €500 → Full MVP €15k-€35k
- Timeline: Landing page 1-3 days → Full MVP 6-10 weeks
- Hybrid approaches: Landing + Concierge, Wizard + Paid pilot, Prototype + Single-feature
- Common mistakes: Building when demand is risk, landing page when delivery is risk, avoiding payment, combining too many types
Then scope it properly using the Must-Have filter.
For launch readiness, see our complete MVP launch checklist.
Next: MVP roadmap: 4-8 weeks—how to plan execution.