TL;DR
The main types of MVP fall into three buckets based on what they validate: manual validation (Concierge, Wizard of Oz), demand validation (Landing page, Fake door, Crowdfunding, Pre-sales, Paid ad, Explainer video), and product validation (Prototype, Single-feature, Piecemeal). Each type tests a different risk with a different amount of effort, and the right one depends entirely on the question you most need answered: can we deliver it, do people want it, or does the product itself work? This guide maps all 11 types, with a real example and a clear "use it when" for each, and links to a full deep dive on every one.
The shortcut: the type you pick should match your riskiest assumption, not your comfort level. At MVP Development we help founders choose the right MVP type and then build it, often a single-feature MVP shipped funding-ready in 3 to 4 weeks on a clear, scoped quote you approve before we start. More on choosing at the end.
Key Takeaways
- The 11 MVP types fall into three buckets by what they validate: manual validation, demand validation, and product validation.
- Manual validation (Concierge, Wizard of Oz) tests whether you can deliver the value.
- Demand validation (Landing page, Fake door, Crowdfunding) tests whether people want it.
- Product validation (Prototype, Single-feature, Piecemeal) tests whether the product itself works.
- Pick the type that matches your riskiest assumption, not your comfort level.
The 3 buckets of MVP validation
Before the individual types, the framework that organizes them. Every MVP validates one of three things, and that is the cleanest way to group them.
| Bucket | The question it answers | Types in it |
|---|---|---|
| Manual validation | "Can we deliver the value at all, by hand?" | Concierge, Wizard of Oz |
| Demand validation | "Do enough people actually want this?" | Landing page, Fake door, Crowdfunding, Pre-sales, Paid ad, Explainer video |
| Product validation | "Does the product itself work and get used?" | Prototype, Single-feature, Piecemeal |
The buckets also roughly map to effort and cost. Demand-validation MVPs are usually the cheapest and fastest (you may build nothing real at all). Manual-validation MVPs cost more in human time than in code. Product-validation MVPs require actually building something. Pick the lightest bucket that answers your real question.
Bucket 1: Manual validation MVPs
These prove you can deliver the value before you automate anything. You do the work by hand, with real customers, and learn what the product actually needs to do.
Concierge MVP
A Concierge MVP delivers your service manually, by hand, to real customers, with no automation hidden or otherwise. You are openly the human doing the work, learning exactly what users need at each step before you build software to do it.
Use it when your product is a service or workflow and you need deep, direct feedback on how it should work. Real example: Airbnb's founders personally went door to door doing professional photography for hosts to test whether better photos drove more bookings, learning the real levers before building any feature.
Read the full guide: Concierge MVP, explained.
Wizard of Oz MVP
A Wizard of Oz MVP looks like a finished, automated product from the outside, but humans perform the work behind the scenes. Unlike the Concierge approach, the user does not know the magic is manual, so they get a realistic product experience while you avoid building the automation.
Use it when you want to test the real user experience of an automated product before paying to automate it. Real example: Zappos started when its founder photographed shoes at local stores, posted them online, and bought and shipped each pair by hand when an order came in, proving people would buy shoes online before building any logistics.
Read the full guide: Wizard of Oz MVP, explained.
Bucket 2: Demand validation MVPs
These answer the single most important startup question, do enough people want this, often without building a real product at all. They are the cheapest and fastest types, and the best first move when your biggest risk is demand.
Landing page MVP
A Landing page MVP is a single web page that describes your product and asks visitors to act: sign up, join a waitlist, or click to buy. It measures interest and captures early users before any product exists.
Use it when you want a fast, cheap read on whether your value proposition resonates. Real example: Buffer started as a landing page that described the product and its pricing, and only built the app after enough people clicked through and signed up to prove demand.
Read the full guide: Landing page MVP, explained.
Fake door MVP
A Fake door MVP advertises a product or feature that does not exist yet. When users click to buy or use it, they hit a "coming soon" message or a signup form. The clicks measure genuine intent, because people are acting as if they would use it.
Use it when you want to test demand for a specific feature or product before building it, especially willingness to pay. The honest caveat: done carelessly it can frustrate users, so keep the follow-up gracious (early access, a discount, a clear explanation).
Read the full guide: Fake door MVP, explained.
Crowdfunding MVP
A Crowdfunding MVP puts your concept on a platform like Kickstarter and asks people to back it with real money before it exists. It validates demand and funds development at the same time, and a strong campaign also builds an early community.
Use it when your product is tangible or visual enough to pitch, and you need both validation and capital. Real example: Pebble raised $10.3M on Kickstarter for its smartwatch, proving demand and funding production in one move.
Read the full guide: Crowdfunding MVP, explained.
Pre-Sales MVP
A Pre-Sales MVP sells the product privately, before it exists, and treats the sales themselves as the experiment. It covers four formats: a refundable deposit, a founding-member deal, a B2B letter of intent, and the pricing page test where you take the intent but not the card. Where crowdfunding tests whether a story sells to an audience, a pre-sale tests whether a solution sells to someone who has the problem.
Use it when you can name a price and can comfortably refund every payment if the test fails. Real example: Buffer put up a pricing page that let visitors pick a plan before revealing the product was not built yet, which measured demand at a specific number rather than in the abstract.
Read the full guide: Pre-sales MVP, explained.
Paid Ad MVP
A Paid Ad MVP buys a small, capped amount of traffic and points it at an offer that does not exist yet, then reads two numbers: whether people click, and what a signup costs. It is the only demand test that reliably reaches strangers who have never heard of you, which makes it the antidote to validating against your own network.
Use it when you have no audience to test against and need a cold read. Real example: countless founders run a few hundred in spend across three or four competing value propositions and discover the winning one describes a different product than they set out to build.
Read the full guide: Paid ad MVP, explained.
Explainer Video MVP
An Explainer Video MVP demonstrates the product working as though it already exists, then measures who signs up after watching. It is the demand test for products that words cannot convey: things that are invisible, run in the background, or only make sense once you see them move.
Use it when the product is hard to describe, expensive to build, or both. Real example: Drew Houston's short screencast of Dropbox took the beta waitlist from around 5,000 to 75,000 overnight, before the sync engine was finished.
Read the full guide: Explainer video MVP, explained.
Bucket 3: Product validation MVPs
These involve building something real, narrow but functional, to test how the actual product performs with real users. Use them once demand is plausible and the remaining risk is the product itself.
Prototype MVP
A Prototype MVP uses an interactive prototype, a clickable, high-fidelity model of the product, to validate the experience and flow with users before committing to a full build. It sits on the boundary between a design prototype and a real MVP: more than a mockup, less than production software.
Use it when the design and flow carry real risk and you want user feedback on the experience before writing production code. Because the line here matters, we cover it in depth in our MVP vs prototype comparison, a pure design prototype is not an MVP, but a functional one used to validate the core task blurs into MVP territory.
Read the full guide: Prototype MVP, explained.
Single-feature MVP
A Single-feature MVP is a real, working product that does exactly one thing, the single core feature that defines your value. Everything else is cut. It is the type most people picture when they hear "MVP," and the one we build most often.
Use it when demand is plausible and you need real usage data on your core flow. Real example: Instagram launched focused purely on fast, filtered photo sharing, and Spotify launched with one thing, instant music streaming, before adding playlists, social, and the rest.
Read the full guide: Single-feature MVP, explained.
Piecemeal MVP
A Piecemeal MVP stitches together existing tools and services to deliver a working product without building each part from scratch. You wire up off-the-shelf software, no-code tools, and APIs to create the core experience cheaply and fast.
Use it when the value can be assembled from existing building blocks and you want to ship without custom engineering. Real example: Groupon's early version was famously cobbled together from a WordPress blog and manually generated PDFs sent by email, before any real platform existed.
Read the full guide: Piecemeal MVP, explained.
All 11 types of MVP compared
Here is the full map in one place, so you can scan and pick.
| Type | Bucket | What it tests | Effort | Example |
|---|---|---|---|---|
| Concierge | Manual | Can we deliver the value by hand? | Medium (human time) | Airbnb |
| Wizard of Oz | Manual | Does the automated experience work? | Medium (human time) | Zappos |
| Landing page | Demand | Does the pitch resonate? | Low | Buffer |
| Fake door | Demand | Will people click to buy or use it? | Low | Feature tests |
| Crowdfunding | Demand | Will people pay upfront? | Low to medium | Pebble |
| Pre-sales | Demand | Will people pay upfront, privately? | Low to medium | Buffer pricing page |
| Paid ad | Demand | Does the promise land with cold strangers? | Low | Any capped ad test |
| Explainer video | Demand | Do people want it once they can see it? | Low to medium | Dropbox |
| Prototype | Product | Does the experience and flow work? | Medium | Design-led builds |
| Single-feature | Product | Does the core feature get used? | Medium to high | Instagram, Spotify |
| Piecemeal | Product | Does the assembled product work? | Low to medium | Groupon |
A closer look at the single-feature MVP
Of the eleven types, the single-feature MVP deserves a closer look, because it is the one most founders end up building and the one most people mean when they say "MVP." It is a real, deployed product that does exactly one thing, the single core feature that defines your value, with everything else deliberately cut.
What makes it powerful is focus. By building one feature well rather than ten features poorly, you get a clean read on whether your core value actually works, and you ship it far faster. Instagram launched as fast, filtered photo sharing, no DMs, no stories, no shop. Spotify launched as instant, gapless streaming, no playlists or social features. Each proved its single core value before adding anything.
The single-feature MVP is usually the destination of the validation ladder, not the starting point. You typically validate demand first (a landing page), maybe test delivery (a Concierge run), and then build the single feature as your first real product. By the time you build it, you are no longer guessing whether anyone wants it; you are confirming that the real, usable version works and retains. This is the type we build most often, shipped funding-ready in 3 to 4 weeks, and the art is choosing which single feature, the scoping discipline at the heart of how to build an MVP.
Which MVP type fits your product
🧭 Not sure which type is yours? Take our free Which MVP Type Should You Build? quiz: four questions, ~30 seconds, and it recommends the leanest type for your situation.
The right type also depends on what you are building, because the riskiest assumption shifts with the product. A quick map:
- SaaS: once demand is plausible, a single-feature MVP is almost always the answer: the one core workflow, built real. Validate demand first with a landing page. See SaaS MVP.
- Marketplace: the hardest assumption is liquidity, so manual types shine early: a Concierge or Wizard of Oz run where you match supply and demand by hand, before building the platform. See Marketplace MVP.
- AI product: a Wizard of Oz MVP (a human behind the "AI") validates that the output is valuable before you build the real model integration, then a single-feature build on a foundation model. See AI MVP.
- Mobile app: usually a single-feature build, because the value is the experience; validate demand with a landing page or fake door first.
- Hardware or a tangible product: crowdfunding is often ideal: it validates demand and funds production at once.
- A service or workflow: start Concierge, deliver it by hand, and learn what to automate before building anything.
The principle holds across all of them: match the type to the riskiest assumption for that product. A marketplace's risk is liquidity; a SaaS tool's is whether the core flow retains; a hardware product's is whether people will pre-pay. The product shapes the risk, and the risk picks the type.
How the buckets map to cost, time, and stage
The three buckets are not just about what you test. They sit at different points on cost, time, and how far along you are, which is why the order usually runs demand, then manual, then product.
| Bucket | Typical cost | Typical time | Best stage to use it |
|---|---|---|---|
| Demand validation | Lowest (often a few hundred dollars) | Days | Earliest, before you build anything |
| Manual validation | Low to medium (your time, not code) | Days to weeks | Once demand looks plausible |
| Product validation | Highest (real engineering) | Weeks to months | Once demand and delivery are plausible |
The pattern is a ladder. Demand-validation MVPs cost almost nothing and answer the question that kills the most startups, no market need, so they belong first. Manual-validation MVPs trade human time for engineering time, ideal for learning how to deliver before you automate. Product-validation MVPs are where you spend real money, so you earn the right to build them by clearing the cheaper rungs first.
This maps onto the wider work of building an MVP. For the dollars behind a real build, see how much an MVP costs; for the calendar, see how long it takes to build an MVP; and for sequencing the build, the MVP roadmap. The MVP type tells you what to build; those guides tell you what it costs, how long it takes, and how to plan it.
Sequencing MVP types: from cheap test to real product
The types are not mutually exclusive, the smartest founders use several in sequence, climbing from cheap validation to a real product, only building as much as the evidence justifies.
A common, proven sequence looks like this. Start with a landing page MVP to test whether the value proposition resonates, the cheapest possible read on demand, live in a day. If people sign up, run a Concierge or Wizard of Oz MVP to deliver the value manually and learn exactly what the product needs to do, trading your time for engineering you have not spent. Only once both demand and delivery are proven do you build a single-feature MVP, the first real, automated product, focused on the one core flow.
Airbnb is the canonical example of this climb: a simple site (demand), founders hosting guests and photographing listings by hand (manual delivery), and only then a real platform (product). Each step de-risked the next, and none of the heavy engineering happened until the cheaper tests had earned it.
The reason to sequence rather than jump straight to a build is economic: each rung is cheaper than the next, and most ideas die on an early rung. Spending engineering time before a landing page has confirmed demand is paying the most expensive price to learn something the cheapest test could have told you. Climb the ladder, and you only ever build what the evidence justifies.
How to choose the right type of MVP
The choice is not about which type is "best," it is about which question your idea most needs answered. Work through it in order:
- Is your biggest risk demand? If you are not sure anyone wants this, start in the demand bucket: a landing page, fake door, or crowdfunding MVP. These are the cheapest, and there is no point building anything until demand is plausible.
- Is your biggest risk delivery? If you are confident people want it but unsure you can deliver the value (especially for a service or complex workflow), use a manual-validation MVP: Concierge to learn openly, Wizard of Oz to test the automated experience.
- Is your biggest risk the product itself? If demand and delivery are plausible and you need real usage data, build a product-validation MVP: a single-feature build for your core flow, a piecemeal assembly if existing tools can carry it, or a prototype MVP if the experience needs validating first.
A useful rule: climb from cheap to expensive. Validate demand before you build, validate delivery before you automate, and build the real product only for the risk that is left. Many founders invert this, building a full product first, which is the most expensive way to learn something a landing page could have told them in a week. That inversion is one of the most common MVP development challenges we see.
Common mistakes when choosing an MVP type
1. Picking the type that feels safe, not the one that answers the risk. Building a real product because it feels more legitimate than a landing page, when demand is the actual unknown.
2. Over-building the manual ones. A Concierge or Wizard of Oz MVP is meant to be scrappy. Automating parts of it defeats the purpose and the savings.
3. Treating a demand test as product validation. A landing page proves interest, not that the product works or retains. Do not skip product validation because the signups looked good.
4. Forgetting the MVP is a stage, not a forever-state. Whichever type you pick, its job is to produce evidence and then graduate. See where it fits in our guide to the MVP stage of a startup.
How MVP types relate to MLP, MMP, and the product-stage terms
It helps to place the MVP types within the wider family of product-stage terms, because founders often confuse a type of MVP with a stage that comes after one.
The eleven types above are all ways to build a minimum viable product, the first version that tests whether an idea works. After the MVP proves the idea, the product evolves through later stages with their own acronyms: the minimum lovable product (MLP), which adds the polish and delight the MVP skipped; the minimum marketable product (MMP), the version with enough features to sell broadly; and the minimum marketable feature (MMF), the smallest feature worth releasing on its own. There are also the terms the MVP gets compared to, the MBI (minimum buyable increment) and SLC (simple, lovable, complete), and the pilot, a controlled test of a near-complete product.
These are not types of MVP; they are points on the product timeline. Knowing the difference keeps you from, say, building an MLP (lovable, polished) when an MVP (minimal, validating) is what the stage calls for. We unpack each in dedicated comparisons: MVP vs MLP, MVP vs MMP, MVP vs MMF, MVP vs MBI, MVP vs SLC, and MVP vs pilot. The takeaway: pick a type to build your MVP now; the stage terms describe where the product goes after the MVP has done its job.
How MVP Development helps you choose and build
There is no single right type of MVP, which is exactly why founders get stuck choosing. We start every engagement with that choice: we help you identify your riskiest assumption and match it to the lightest MVP type that can test it, with no pressure to over-build. If a landing page or a Wizard of Oz test is the honest answer, we will tell you, and it will save you money.
When the answer is a real product, which it often is once demand is plausible, we build it for you: most commonly a single-feature MVP, shipped funding-ready in 3 to 4 weeks, built by senior engineers, on a clear, scoped quote you approve before we start. You get an unbiased recommendation on the type and the team to execute it, in one place. For the budget behind each path, see our guide to how much it costs to build an MVP.
Not sure which type fits your idea? Tell us your idea and your constraints and we will recommend which of these types fits, with the reasoning.
Related guides
- What Is an MVP?: the full definition of a minimum viable product, and what makes one work
- MVP Glossary: every MVP term defined in one place, including all 11 types above
- MVP Examples: 15 Famous MVPs: see these MVP types in action at Airbnb, Dropbox, Uber, and more
- How to Build an MVP: the step-by-step process from idea to launch
Frequently asked questions
What are the main types of MVP?
The main types of MVP fall into three validation buckets. Manual validation: Concierge and Wizard of Oz. Demand validation: Landing page, Fake door, and Crowdfunding. Product validation: Prototype, Single-feature, and Piecemeal. Each tests a different risk, can we deliver it, do people want it, or does the product work, with a different amount of effort.
What is the most common type of MVP?
The single-feature MVP is the type most people picture and the one most startups build: a real, working product that does one core thing well, with everything else cut. Instagram (photo sharing) and Spotify (streaming) both launched this way. It is the default once demand is plausible and you need real usage data on your core flow.
What is the difference between a Concierge and a Wizard of Oz MVP?
Both deliver the value manually, but the difference is transparency. In a Concierge MVP the customer knows a human is doing the work, which is ideal for learning openly. In a Wizard of Oz MVP the product looks fully automated and the manual work is hidden, which gives a realistic product experience while you avoid building the automation.
Which type of MVP is cheapest?
Demand-validation MVPs are usually the cheapest and fastest, because you often build nothing real. A landing page or fake door MVP can be live in days for very little money and still produce a clear signal on whether people want your product. Build something more expensive only once demand looks plausible.
Is a prototype a type of MVP?
It depends on the prototype. A pure design prototype (a clickable mockup with no real functionality) is not an MVP, it is a design artifact. But a functional, interactive prototype used to validate the core experience with real users blurs into MVP territory. We unpack the boundary in detail in our MVP vs prototype comparison.
How do I choose the right type of MVP?
Match the type to your riskiest question. If the risk is demand, use a demand-validation MVP (landing page, fake door, crowdfunding). If the risk is whether you can deliver the value, use a manual one (Concierge, Wizard of Oz). If the risk is the product itself, build a product-validation MVP (single-feature, piecemeal, or prototype). Always pick the lightest type that genuinely answers your question.
Can you combine different types of MVP?
Yes, and founders often do, in sequence. A common path is a landing page to validate demand, then a Wizard of Oz or Concierge run to learn how to deliver, then a single-feature build as the first real product. Each step de-risks the next. You are climbing from cheap validation to a real product, only building as much as the evidence justifies.
Which type of MVP should a SaaS startup use?
Most SaaS startups validate demand first with a landing page MVP, then build a single-feature MVP, a real product centered on the one core workflow that delivers value. The single-feature type is the SaaS default because SaaS value lives in a repeatable core flow (sign-up to first value), and you need real usage and retention data to validate it. A Concierge or Wizard of Oz run can come in between if you need to learn how the workflow should function before automating it. See our SaaS MVP guide for the full approach.
How many types of MVP are there?
The main types of MVP are usually grouped into eleven, across three validation buckets: manual validation (Concierge, Wizard of Oz), demand validation (Landing page, Fake door, Crowdfunding, Pre-sales, Paid ad, Explainer video), and product validation (Prototype, Single-feature, Piecemeal). Some lists add variants like the explainer-video MVP (a demand test, famously used by Dropbox), but they fold into these same buckets. What matters is not the exact count but matching the validation approach to your riskiest assumption.
Is the single-feature MVP the same as a minimum viable product?
A single-feature MVP is one type of minimum viable product, the most common one, where the MVP is a real product built around a single core feature. "MVP" is the broad concept (the smallest version that validates an idea), and the single-feature build is the specific form most startups use once demand is plausible. The other forms (landing page, Concierge, and so on) are also MVPs; they just validate the idea in different, often cheaper, ways before any single feature gets built.
Sources and references
This guide draws on established MVP frameworks and well-documented startup examples:
- Userpilot, Types of Minimum Viable Product the landscape of MVP types
- LogRocket, Concierge vs Wizard of Oz MVP the manual-validation distinction
- Shortform, The Dropbox MVP Explainer Video a demand-validation classic
- Eric Ries, The Lean Startup the origin of the MVP concept
Examples (Airbnb, Zappos, Buffer, Pebble, Instagram, Spotify, Groupon) are widely documented startup histories; the 3 to 4 week figure reflects MVP Development delivery data for single-feature builds.
