Types of MVP: Which Approach Fits Your Idea?
“MVP” gets used as if it means one specific thing, but in practice it covers a spectrum — from a single landing page testing whether anyone cares, to a fully coded product handling real transactions. Picking the wrong type for your stage of uncertainty is a common, expensive mistake.
The right MVP type depends entirely on what you’re actually unsure about. Different types of MVP are built to answer different kinds of questions.
The Main Types of MVP
Landing Page MVP
A single page describing the product, with a call to action (sign up, join a waitlist, pre-order). This tests raw interest before any product exists. It’s the cheapest and fastest way to gauge whether a problem resonates enough for people to take action.
Concierge MVP
The team manually delivers the outcome the eventual product would automate — for example, personally matching clients to service providers before building a matching algorithm. This validates whether the outcome itself is valuable, and often surfaces workflow details that would otherwise be missed until much later.
Wizard of Oz MVP
Users interact with what looks like an automated product, but a person is doing the work behind the scenes. This differs from a concierge MVP mainly in framing — users believe they’re using software, which better tests real usage behavior than a concierge model where they know a human is involved.
Single-Feature MVP
A coded product focused on one core capability, deliberately excluding secondary features. This is the most common type once a team has enough confidence in demand to justify writing real software, and is what most people mean by “MVP” in a startup context.
Piecemeal MVP
The product stitches together existing tools and services (spreadsheets, no-code platforms, third-party APIs) rather than custom-coding every part. This can validate a product faster and cheaper, with the understanding that some pieces will be replaced with custom-built components later.
MVP vs. Proof of Concept (POC)
These two are frequently confused, but they answer different questions:
| Aspect | MVP | Proof of Concept (POC) |
|---|---|---|
| Question answered | Do real users want this, and will they use/pay for it? | Is this technically possible at all? |
| Built for | Real users | Internal team or technical stakeholders |
| Typical scope | A complete (if minimal) user journey | A narrow technical test, often not user-facing |
| When to use | When commercial demand is the main uncertainty | When a critical technology is unproven (AI accuracy, complex integrations, novel hardware) |
If your biggest question is “can this even work technically,” build a POC first. If your biggest question is “will anyone actually use this,” an MVP — likely one of the lighter-weight types above — is the better starting point. Our guide on 10 signs your product idea is ready for MVP development is a useful gut-check for which stage you’re actually at.
Choosing the Right Type for Your Uncertainty
Ask yourself which of these is true for your product right now:
- “I don’t know if anyone wants this at all.” → Start with a landing page or concierge MVP.
- “I’m fairly confident in demand, but unsure about the workflow.” → A wizard of oz or piecemeal MVP can validate the experience before full development.
- “I know people want this, and I need to prove it can operate at real scale.” → A single-feature coded MVP is the right next step.
- “I’m unsure if the core technology will work at all.” → Build a POC first, separate from any user-facing MVP.
A Common Mistake: Jumping Straight to a Full Coded Build
Many founders skip the lighter-weight MVP types entirely and go straight to a fully coded product, assuming that’s what “MVP” requires. This is usually a mistake if your core uncertainty is about demand rather than execution — a landing page or concierge test can validate the same question for a fraction of the cost and time, and the lessons learned often change what the eventual coded MVP should even include.
If you do need a coded MVP because demand is already established, our breakdown of what’s actually included in MVP development services is a useful reference for what a properly scoped build should cover.
Moving From MVP to Full Product
Whichever type you start with, the goal is the same: generate real evidence as cheaply as possible, then use that evidence to decide what to build next. A concierge or landing page MVP that shows strong demand naturally leads into scoping a coded single-feature MVP — the types aren’t mutually exclusive, they’re stages.
Not Sure Which MVP Type Fits Your Idea?
MVPHUB helps founders choose the right validation approach before committing to a full build — whether that's a lightweight test or a production-ready MVP. Book a free consultation with MVPHUB to talk through your options.
Book a free consultation with MVPHUBFrequently Asked Questions
What are the main types of MVP?
The main types include concierge MVPs (manually delivering the service behind the scenes), wizard of oz MVPs (a front end that looks automated but is manually operated), landing page MVPs (testing demand before building), single-feature MVPs, and fully coded MVPs.
What is the difference between an MVP and a proof of concept?
A proof of concept tests whether something is technically possible, usually not intended for real users. An MVP is a functioning product built for real users, intended to generate evidence about demand and behavior, not just technical feasibility.
What is a concierge MVP?
A concierge MVP delivers the product's value manually, with a person performing tasks a future automated system would handle, allowing a team to test demand and refine the offering before writing production code.
What is a wizard of oz MVP?
A wizard of oz MVP presents users with what looks like an automated product, while the actual work happens manually behind the scenes, letting a team validate demand before investing in the automation itself.
Which type of MVP should I choose?
Choose based on your biggest uncertainty. If you're unsure whether people want the outcome at all, start with a landing page or concierge test. If you're confident in demand but unsure about a specific workflow, a single-feature coded MVP is usually the better next step.
Can I combine multiple types of MVP?
Yes. Many successful products start with a landing page or concierge test to validate demand, then move to a coded single-feature MVP once there's evidence worth building software around.
