Types of Minimum Viable Product in 2026: Which One Should You Build?

I work as a PM at Userpilot, and the proliferation of MVP types hasn’t made any team I’ve worked with any better at choosing the right way to validate market demand with potential customers.

There are now somewhere between fifteen and twenty-three named types in active circulation: landing pages, fake doors, explainer videos, Wizards of Oz, Concierges, paid pilots, plus rebrands like MLP, MMP, SLC, and RAT that each promise a smarter version of the same idea.

Most of these labels describe the same handful of decisions you’ll face when validating a product idea, just in different vocabulary.

What makes this worth revisiting in 2026 is that AI prototyping tools like v0, Bolt, Lovable, Cursor, and Replit Agent have brought the cost of building most MVP types down to a weekend. Your bottleneck is no longer “can we build this?” but “are we building the right test?”, and with 23 labels to pick from, you’re going to grab the wrong test more often than you’d like.

So let me help you debunk all the myths and see which MVP type works.

What are people talking about when they say “types of MVP”?

Quite a few different things, and that’s part of the problem. The labels in active circulation fall into four buckets, and people use them interchangeably even though each bucket is solving a different problem.

1. On the no-code end, you have the landing page MVP, the explainer video MVP, the fake door MVP, pre-orders, waitlists, and crowdfunding campaigns. Each one picks a different conversion action to gauge interest as a signal of customer demand, and none of them requires you to write any code.
2. One step up, the prototype tier covers paper prototypes, Figma mockups (sometimes called a high fidelity MVP), and sales demos. You use these to test interaction or pitch and collect early user feedback before you have a working backend behind anything.
3. The functional product tier is where you’re shipping a basic version with just enough functionality to test the essential features: single-feature MVPs, Wizards of Oz, Concierge services, piecemeal no-code stacks, and Micro-SaaS products. If you work in B2B or enterprise, the list also includes paid pilots, design partner engagements, internal MVPs, and sub-products launched inside an existing platform, the way we launched Lia at Userpilot or Ahrefs launched Agent A.
4. Sitting on top of all that are the rebrands: MLP (Minimum Lovable Product), MMP (Minimum Marketable Product), SLC (Simple, Lovable, Complete), RAT (Riskiest Assumption Test), MAP, MWP, MFHP, and MBP. Each one came out of someone arguing that an earlier label couldn’t thoroughly explain. MLP, for instance, came from the argument that customer dissatisfaction with what’s on the market rarely drives a switch unless the new option is clearly better. Eventually, the list keeps growing.

Do these MVP types work as different things, or are they the same idea?

Mostly the same idea in different clothing.

Marty Cagan from Silicon Valley Product Group named this problem years ago. He distinguishes between an “MVP Test” (the core concept from the lean startup methodology) and an actual product, and argues that conflating the two is what causes so much of the confusion.

Most items on the 23-type list belong on the experiment side.

Take a Kickstarter campaign, an explainer video, a landing page, or a fake door. Each one is a demand test using a different conversion signal: pre-payment, concept comprehension, click-through, or intent to wait in a queue. They all ask the same underlying question, which is whether anyone in your target audience, especially the early adopters, wants the thing.

The prototype tier has the same issue. A Figma mockup or a paper prototype is a UX experiment that uses task completion as its signal. People apply the MVP label to these widely, but the label doesn’t change what they’re doing, which is testing whether the interaction and value proposition make sense before you commit to a build.

The functional product tier is where you’re closer to shipping something, and there’s not even a distinct difference here. The supposed difference between the Oz MVP, the Concierge MVP, single-feature MVPs, and piecemeal MVPs built from existing tools comes down to two yes-or-no variables: whether the backend runs on automation or human work, and whether the user knows which. Two variables give you four combinations rather than four distinct product types. An Oz MVP creates the appearance of automation while humans do the work behind the scenes; a Concierge MVP makes that manual work explicit.

As for the rebrands, each one argues for a different definition of “viable” rather than a different kind of product.

• MLP, MAP, and MWP mean you ship a more mature product.
• MMP and MBP all focus on marketability and revenue.
• SLC rejects the word “minimum” entirely, and MFHP prioritizes product depth over feature count.

What they all share is a focus on “good enough” rather than the structure of the product. RAT sits one level above the entire taxonomy as the step that decides which hypothesis you should test first, and Itamar Gilad’s evidence-based framework for product validation treats it as the deciding factor of whether you should run an MVP at all.

Strip the labels, and you’re left with a much smaller list of underlying tests, all aimed at the same goal of validated learning.

How should you decide which type of MVP to build?

I’d say pick the hypothesis you’re least sure about, then pick the method that gives you the strongest signal on that hypothesis. The three hypotheses each test a different layer of customer needs.

• The first is demand: Do they want it? You’re trying to find out whether anyone takes an action that signals serious interest.
• The second is behavior: Will they use it? You’re trying to find out whether user behavior matches what you expected, with people completing the core loop and coming back once you put a working version in their hands.
• The third is willingness to pay: Will they pay for it? You’re trying to find out whether your users will convert money into product access at a price that supports the business. This is where product-market fit becomes measurable.

Here are all three side by side:

Where I see teams go wrong is the other direction: they pick the method that’s easiest to build, run it, and try to back-fit a hypothesis onto whatever signal the artifact happened to produce. A landing page with five thousand email sign-ups looks like demand validation, but if your bigger uncertainty was willingness to pay, then those emails told you almost nothing.

At Userpilot, we apply the same rule when we test new features inside our own product. We name the hypothesis first, then pick the method, and our engagement tools are built so you can run the test in-product without writing code, whether you’re putting up a fake door, an onboarding experiment, or a survey to gather customer feedback.

How does AI prototyping change all of this?

It makes the choice more difficult than it was, because speed compounds in whichever direction you’re already pointed.

AI prototyping tools like v0, Bolt, Lovable, Cursor, and Replit Agent have brought the cost of building most functional MVP types down from months to days. You can ship an early product version with a single feature over a weekend, and Figma AI can generate a clickable prototype for you from a single prompt.

Nonetheless, just because you can build in a weekend doesn’t mean you should. Before kicking off the development process, you should be clear on what you’re trying to learn and what method you should use.

Even at Userpilot, where our AI agent Lia helps us flag adoption anomalies and suggest in-app guidance from user feedback after launch, the AI doesn’t tell us what to build. It only helps us read what’s happening once we know what to build.

What happens after shipping your MVPs?

Your problem changes from “should we build this?” to “is anyone using what we built?”, and you need analytics that don’t require engineering work to instrument every event so you can read customer behavior at scale.

At Userpilot, we built our tooling to do both jobs: shipping the MVP and measuring what happens after launch. Our product analytics helps you track feature adoption among your existing customers and surface drop-off points on the core features you’ve shipped, and Lia, our Product Growth AI Agent, picks up from there. It spots the friction, drafts the in-app fix, ships it at the autonomy level you set, and monitors what works.

Validating an idea is one problem, and knowing whether anyone uses what you built is a different one. The same logic applies across the entire product development journey, where you pick the question you’re trying to answer first, then pick the method to gather feedback. So book a demo with us to see how this works in practice!

About the author

Abrar Abutouq

Product Manager

Product Manager at Userpilot – Building products, product adoption, User Onboarding. I'm passionate about building products that serve user needs and solve real problems. With a strong foundation in product thinking and a willingness to constantly challenge myself, I thrive at the intersection of user experience, technology, and business impact. I’m always eager to learn, adapt, and turn ideas into meaningful solutions that create value for both users and the business.

All posts