A brilliant product idea can make a founder feel ten feet tall. Then the development estimate arrives, the budget starts sweating, and someone quietly asks, “Are we sure customers actually want this?”
That uncomfortable question is exactly why the minimum viable product exists. Popularized through the Lean Startup approach, an MVP is the smallest practical version of an idea that allows a team to test an important assumption and gather meaningful customer feedback. It is not supposed to be a cheap, half-working product tossed onto the internet with crossed fingers. It is a learning tool designed to reduce uncertainty before a company invests heavily in development.
Different assumptions require different MVP formats. A landing page may reveal whether people understand your value proposition, while a concierge MVP can show whether the service delivers enough value to justify payment. The best type of MVP is therefore not the one that looks most impressive. It is the one that produces the clearest evidence with the least unnecessary effort.
Below are 12 types of minimum viable product, along with their advantages, disadvantages, ideal use cases, and practical examples.
What Makes an MVP Truly Viable?
Before comparing MVP types, it helps to separate “minimum” from “viable.” Minimum describes the amount of work required. Viable means the experiment must still provide enough value, credibility, or realism to generate useful behavior from potential customers.
A form that collects email addresses may be viable for testing interest in an upcoming newsletter. The same form would not be viable for proving that customers will pay $200 per month for financial software. That hypothesis requires stronger evidence, such as a deposit, paid pilot, or working service.
A good MVP should answer a specific question:
- Do customers experience the problem we identified?
- Do they understand and want our proposed solution?
- Will they sign up, place an order, or pay for it?
- Can we deliver the promised result reliably?
- Will users return after trying the product?
If your MVP cannot produce evidence related to one of those questions, it may be a prototype, demonstration, or very attractive science projectbut not yet a useful market experiment.
1. Paper Prototype MVP
A paper prototype is a hand-drawn representation of a product interface, workflow, or physical concept. Users interact with sketches while a facilitator changes screens, moves paper elements, or asks participants to explain what they expect to happen.
This method is especially useful for testing navigation, page hierarchy, checkout flows, onboarding sequences, and early physical product concepts. Nielsen Norman Group has long recommended paper prototyping as an inexpensive way to identify usability problems before development begins.
Pros
- Extremely inexpensive and fast to create.
- Encourages honest feedback because the design clearly is not finished.
- Makes major revisions painless.
- Works before any code or technical architecture exists.
Cons
- Cannot test performance, automation, or real-world reliability.
- May feel too abstract for some participants.
- Produces limited evidence about willingness to pay.
Best for: Testing usability, information architecture, screen flow, and early design concepts.
2. Clickable Prototype MVP
A clickable prototype resembles a functioning website or application, but many of its buttons lead to predefined screens rather than live systems. It gives users a realistic sense of navigation without requiring databases, integrations, payment processing, or a fully engineered backend.
Clickable prototypes can range from low-fidelity wireframes to polished interfaces that look almost production-ready. The important point is that each version should test a design hypothesis rather than simply impress stakeholders with shiny buttons.
Pros
- More realistic than a paper prototype.
- Useful for usability tests, investor demonstrations, and customer interviews.
- Cheaper than building a functional application.
- Allows teams to compare multiple user flows quickly.
Cons
- Users may assume the product is more complete than it is.
- Cannot validate backend feasibility or system performance.
- Positive reactions may not translate into purchases.
Best for: Testing digital interfaces, navigation patterns, onboarding, and feature comprehension.
3. Explainer Video MVP
An explainer video demonstrates what a proposed product will do, how it will work, and why customers should care. The product itself may not exist yet.
Dropbox is the classic example. Before building a massive cloud-syncing operation, its early demonstration video helped communicate a technically difficult concept and measure interest among potential users. The video did not prove every engineering assumption, but it offered a fast way to test whether the idea resonated.
Pros
- Explains complex or unfamiliar ideas clearly.
- Can attract signups before full development.
- Costs less than building technically demanding functionality.
- Useful for measuring message clarity and early demand.
Cons
- Viewers may like the video but never use the product.
- Does not validate technical feasibility.
- A polished presentation can exaggerate actual customer interest.
Best for: Products involving unfamiliar technology, new behavior, or functionality that is expensive to build.
4. Landing Page MVP
A landing page presents a product’s value proposition, target customer, primary benefits, price, and call to action. The call to action might invite visitors to join a waiting list, request a demonstration, start a trial, or reserve the product.
Teams can run advertisements or outreach campaigns to measure visits, signups, conversion rates, and differences between customer segments. Landing-page experiments can also compare positioning, pricing, headlines, and offers before significant development begins.
Pros
- Fast and relatively inexpensive to launch.
- Tests messaging and audience interest.
- Can collect qualified leads.
- Supports A/B testing of offers and positioning.
Cons
- Email signups are weaker evidence than purchases.
- Results depend heavily on traffic quality.
- A poorly written page may make a good idea appear unattractive.
Best for: Testing demand, value propositions, customer segments, lead generation, and early pricing.
5. Smoke-Test or Painted-Door MVP
A smoke test advertises a product or feature before it has been fully built. A painted-door experiment places a visible button, menu item, product listing, or feature description in front of users and measures whether they attempt to use it.
For example, a software company might add an “Automated Reports” option to its dashboard. When users select it, they see a message explaining that the feature is being developed and inviting them to join an early-access list.
Pros
- Measures actual clicks rather than interview enthusiasm.
- Helps prioritize competing features.
- Can be implemented without building the complete feature.
- Works well inside an existing product.
Cons
- Can frustrate users when handled poorly.
- Requires transparent messaging to preserve trust.
- A click indicates curiosity, not necessarily long-term demand.
Best for: Testing feature interest, menu placement, upgrade demand, and proposed product extensions.
6. Email or Newsletter MVP
An email MVP delivers information, recommendations, reports, alerts, or curated content manually through email. Instead of building a dashboard or mobile application, the team provides the core value through a channel customers already use.
A founder considering a personalized travel-planning platform, for example, might begin by sending subscribers customized weekend itineraries. This tests whether users value the recommendations before anyone builds a booking engine capable of having a nervous breakdown at 3:00 a.m.
Pros
- Requires little technical development.
- Creates a direct customer-feedback channel.
- Makes engagement easy to measure through opens, clicks, replies, and conversions.
- Can begin with a very small audience.
Cons
- Manual personalization becomes time-consuming.
- Email behavior may differ from in-product behavior.
- Deliverability issues can distort results.
Best for: Curated information services, recommendations, reports, education products, and early B2B services.
7. Preorder or Crowdfunding MVP
A preorder MVP asks customers to reserve or purchase a product before full production. Crowdfunding campaigns use a similar principle by presenting the concept, explaining expected delivery, and asking supporters to provide money.
This approach produces stronger evidence than gathering email addresses because customers must make a financial commitment. It can also help finance production, although spending customer money before solving manufacturing problems is a thrilling way to discover new varieties of stress.
Pros
- Tests willingness to pay.
- Can generate working capital.
- Provides early estimates of demand.
- Builds a community of initial customers.
Cons
- Creates legal, financial, and reputational obligations.
- Production delays may upset supporters.
- Campaign performance can depend on marketing quality.
- Strong launch interest does not guarantee repeat demand.
Best for: Consumer products, hardware, creative projects, courses, books, and products with predictable production requirements.
8. Concierge MVP
In a concierge MVP, customers know that humans are delivering the service manually. The team works closely with a small number of users, handling tasks that may eventually become automated.
Suppose a startup wants to build an artificial intelligence tool that creates weekly meal plans. Before training models and connecting grocery databases, the founders could interview ten families and prepare each plan manually. Customers receive the promised outcome while the team observes their preferences, objections, and repeated requests.
Pros
- Produces detailed customer insights.
- Tests whether the outcome provides real value.
- Allows immediate changes without rewriting software.
- Can generate revenue early.
Cons
- Difficult to scale.
- Manual delivery may hide automation challenges.
- Founder involvement can create an unrealistically premium experience.
- Labor costs may become substantial.
Best for: Service businesses, recommendation engines, B2B workflows, marketplaces, and products with uncertain customer requirements.
9. Wizard of Oz MVP
A Wizard of Oz MVP appears automated to the customer, while people perform some or all of the work behind the scenes. The user interacts with a convincing storefront, application, or interface without seeing the manual machinery backstage.
Strategyzer describes this approach as presenting a realistic front stage while manually completing the tasks that a future automated system would handle. It is useful when automation is expensive but the customer experience can be simulated responsibly.
Pros
- Tests the intended customer experience.
- Delays expensive automation.
- Reveals operational requirements and unusual cases.
- Allows teams to improve the process before coding it.
Cons
- Manual operations can become chaotic quickly.
- Customers may feel misled if transparency is inadequate.
- Does not prove that automation will be technically or economically feasible.
Best for: Artificial intelligence tools, marketplaces, logistics platforms, recommendation products, and automated business services.
10. Piecemeal MVP
A piecemeal MVP combines existing tools and services to deliver a new customer experience. Instead of building custom scheduling, payment, messaging, analytics, and automation systems, a startup connects available products and adds only the missing pieces.
A tutoring marketplace might combine a website builder, online forms, video meetings, calendar software, payment processing, spreadsheets, and manual customer support. It may not win an architecture beauty contest, but it can begin serving customers before a custom platform exists.
Pros
- Reduces engineering time and initial cost.
- Uses proven third-party capabilities.
- Can become operational quickly.
- Helps document requirements for a later custom system.
Cons
- Creates a fragmented user experience.
- Third-party pricing and policies may change.
- Integrations can become unreliable.
- Data may be scattered across several systems.
Best for: Marketplaces, operational services, internal tools, early SaaS products, and businesses that can assemble value from existing technology.
11. Single-Feature MVP
A single-feature MVP delivers one core capability exceptionally well. Rather than building an entire platform, the team focuses on the smallest complete workflow that solves a meaningful customer problem.
For a project-management product, the first release might only allow users to assign tasks and track deadlines. It would omit team chat, advanced analytics, invoicing, artificial intelligence, animated celebrations, and the other features waiting eagerly in the roadmap.
Pros
- Keeps development focused.
- Makes the product easier to explain.
- Produces clear usage data around the core benefit.
- Reduces the risk of building unwanted secondary features.
Cons
- The feature may not provide enough standalone value.
- Customers may compare it with mature competitors.
- Important supporting functions may still be required for viability.
Best for: Software products with one identifiable primary job or teams testing a minimum viable feature inside an existing platform.
12. No-Code or Low-Code Functional MVP
A no-code or low-code MVP is a working product created with visual development platforms, automation tools, templates, and reusable components. Unlike a clickable prototype, it performs real operations and can often support actual customers.
This approach is useful when speed matters more than perfect architecture. Microsoft startup guidance recommends beginning with simple models and maximizing learning before making heavier technical investments. Low-code tools can also reduce prototype and MVP development time in suitable business scenarios.
Pros
- Faster than custom development in many cases.
- Can process real data and transactions.
- Accessible to founders with limited programming experience.
- Supports rapid updates after customer feedback.
Cons
- May introduce performance or customization limits.
- Platform dependence can complicate future migration.
- Security and compliance require careful review.
- Subscription and usage fees may grow with scale.
Best for: Workflow applications, directories, portals, internal tools, simple SaaS products, and early marketplaces.
How to Choose the Right Type of MVP
Do not begin by asking, “Which MVP can we build?” Begin with, “What must we learn?” The riskiest assumption should determine the experiment.
- To test whether customers understand the idea: Use an explainer video or landing page.
- To test usability: Use a paper or clickable prototype.
- To test feature demand: Use a smoke test or painted door.
- To test whether the outcome creates value: Use a concierge or Wizard of Oz MVP.
- To test willingness to pay: Use a preorder, paid pilot, or functional MVP.
- To test repeated usage: Use a single-feature, piecemeal, or no-code product.
Y Combinator’s guidance generally encourages founders to build lean initial products in weeks rather than disappearing into development for months. Speed matters because market feedback is usually more useful than another conference-room debate about what customers might theoretically do.
Experience-Based Lessons From Running MVP Experiments
The most useful MVP lessons rarely come from perfect launches. They come from watching people misunderstand a button, ignore a carefully written benefit, abandon a checkout, or ask for a feature the team assumed nobody needed. Those moments may bruise the ego, but they save far more money than compliments from friendly interview participants.
Test One Risky Assumption at a Time
Teams often try to make one MVP test the market, user interface, pricing, acquisition strategy, retention, and scalability simultaneously. The result is a pile of numbers that can support almost any conclusion. A better experiment starts with one falsifiable statement, such as: “Independent accountants will pay $49 per month to automate weekly client reminders.”
That statement identifies a customer, problem, solution, price, and behavior. The team can now choose an MVP that produces relevant evidence instead of collecting random applause.
Behavior Is Stronger Than Praise
Potential customers are generous during interviews. They say an idea is interesting, useful, clever, and something they would “definitely check out.” Unfortunately, compliments cannot pay hosting bills.
Evidence becomes stronger as commitment increases. Viewing a video is weaker than joining a waiting list. Joining a list is weaker than scheduling a demonstration. Scheduling a demonstration is weaker than entering payment information. Paying is stronger still, while paying and returning repeatedly is the kind of evidence product teams frame and hang above the coffee machine.
Manual Work Is Not Automatically a Failure
Founders sometimes avoid concierge and Wizard of Oz MVPs because manual work feels unscalable. That misses the point. The first goal is not to serve one million customers. It is to understand what must happen before automation is worth building.
Manual delivery reveals exceptions, customer language, decision rules, support questions, and hidden costs. It shows whether the process has consistent steps or whether every order requires a heroic rescue mission. Those observations become requirements for future software.
Charge Earlier Than Feels Comfortable
Free users can validate usability and engagement, but they cannot fully validate a business model. Even a modest payment changes the conversation. Customers become more specific about expectations, compare the offer with alternatives, and reveal which outcomes justify the price.
A paid pilot may be more informative than hundreds of free registrations. However, teams should describe limitations clearly. An MVP is not a permission slip to hide defects, ignore security, or sell vapor in a fashionable landing-page wrapper.
Choose Metrics Before Launching
Without predefined success criteria, every outcome can be declared “promising.” Decide in advance what evidence will support, weaken, or reject the hypothesis. Relevant measurements might include activation, task completion, conversion, payment, repeat usage, retention, support requests, or time saved.
Traffic and cumulative signups can look impressive while hiding poor adoption. Product analytics guidance therefore emphasizes metrics tied to user value, feature adoption, engagement, and retention rather than isolated vanity numbers.
Protect Trust While Experimenting
MVPs should be small, not reckless. Products involving money, health, identity, safety, or sensitive data require appropriate security, privacy, legal review, and quality controls from the beginning. A company can postpone decorative dashboards. It cannot postpone basic responsibility.
Teams should also avoid misleading users about product availability or automation. Painted-door and Wizard of Oz tests work best when disappointment is minimized, expectations are managed, and participants receive a reasonable explanation.
Stop, Iterate, or Expand Deliberately
An MVP is valuable only when the team acts on what it learns. Strong evidence may justify expanding the product. Mixed evidence may require a revised customer segment, price, workflow, or value proposition. Consistently weak evidence may mean the team should stop.
Stopping is not necessarily failure. Spending two weeks discovering that a product should not be built is far better than spending eighteen months discovering the same thing with custom office furniture and a much larger cloud-computing bill.
Conclusion
There is no universally superior type of minimum viable product. A paper prototype may be perfect for identifying navigation problems but useless for testing willingness to pay. A preorder can demonstrate financial commitment but cannot prove long-term retention. A concierge service reveals detailed customer needs, while a no-code MVP allows people to complete a real workflow.
The right MVP is the smallest credible experiment capable of testing your most dangerous assumption. Define what you need to learn, identify the customer behavior that would count as evidence, and select the format that produces that behavior with minimal unnecessary development.
Build enough to learnnot enough to impress every imaginary customer, satisfy every stakeholder, or keep the feature backlog from feeling lonely. Once real users respond, you can improve the product with evidence rather than optimism wearing a spreadsheet.
Research note: This article synthesizes product-development guidance and case material from Lean Startup, Atlassian, Strategyzer, Nielsen Norman Group, Microsoft for Startups, ProductPlan, Y Combinator, TechCrunch, Unbounce, Optimizely, Mailchimp, and Mixpanel.
