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), 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 8 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 HorizonLux we help founders choose the right MVP type and then build it, often a single-feature MVP shipped funding-ready in under 4 weeks for a fixed $2,999. More on choosing at the end.
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 |
| 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.
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 8 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 |
| 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 |
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.
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 HorizonLux 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 under 4 weeks for a fixed $2,999, built by senior engineers. 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 about it and we will help you choose, then build it.
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.
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 four-week, $2,999 figure reflects HorizonLux delivery data for single-feature builds.
