There are 10 practical types of MVP, from a one-page landing test to an AI-powered workflow with people behind it. Each type answers a different question: will people want it, use it, or pay for it. This guide covers each type with a real startup example, typical cost and timeline, and a simple method for picking the right one.
Key Takeaways
Dropbox grew its beta waitlist from 5,000 to 75,000 overnight with a three-minute demo video and no public product.
Buffer tested pricing with a two-page site, then reached 500+ users and about 4% paid conversion within roughly 2.5 months.
Pick your MVP type by your riskiest assumption: demand, usage or willingness to pay.
No-code MVPs take days to two weeks and cost up to about $5,000. A coded SaaS MVP takes 8 to 12 weeks.
42% of the 101 failed startups CB Insights studied had no market need for their product.
You have an idea and a limited budget.
A developer quotes three months and a five-figure price. You build, launch, and wait for signups that never come.
That outcome is common, and it is expensive. Founders who skip cheap tests spend their runway on guesses.
This guide explains the 10 types of MVP, from landing pages to AI-assisted workflows. Each has a real startup example, a typical cost, and a clear use case.
You will also learn how to pick the right type for your idea and what to build before you write code.
The stakes are real. CB Insights analyzed 101 startup post-mortems and found that 42% failed because there was no market need.
What Are the Types of MVP?
The types of MVP are 10 formats for testing a product idea at the lowest possible cost. They range from no-code demand tests, such as a landing page, to coded products, such as a single-feature app.
Eric Ries popularized the MVP in The Lean Startup. An MVP is the smallest experiment that tests a specific hypothesis about whether something is worth building.
An MVP is an approach, not a specific product. The format you choose depends on what you need to learn.
Userpilot counts 15 to 23 named MVP labels in circulation. Most describe the same few decisions in different words.
We narrowed the list to 10 formats that differ in what you actually build.
Group
MVP types
What you build
Demand tests (no code)
Landing page, explainer video, pre-order
A page, a video or a campaign
Manual-delivery tests
Concierge, Wizard of Oz, piecemeal
A service delivered by hand or with existing tools
Coded tests
Single-feature, private beta, internal-first, AI human-in-the-loop
Working software with a narrow scope
Each group answers a different question.
Demand tests ask whether anyone wants it. Manual tests ask whether the outcome is valuable.
Coded tests ask whether people keep using it.
What Is the Difference Between an MVP, a Prototype and a Proof of Concept?
The main difference is what each one is designed to validate: an MVP tests a product with real users, a prototype shows how a product could look or work, and a proof of concept shows whether a technical idea is feasible. Understanding MVP vs prototype can help you choose the right approach for the stage of your product. Each answers a different question at a different cost.
Term
Question it answers
Real users?
Typical output
Proof of concept
Can we build this?
No
A working test of the riskiest technical feature
Prototype
Will the flow make sense?
A few testers
A clickable or functional mockup
MVP
Will people use or pay for it?
Yes
A live product or manual service
MMP
Can we sell it without apology?
Yes, paying
A launch-ready version for paying customers
Userpilot notes that a Figma mockup is a UX experiment, and the MVP label does not change what it tests.
Treat the first three as steps on one path. A proof of concept removes technical risk, a prototype removes design risk, and an MVP removes market risk.
Technource prices proof of concept and prototype work separately from the MVP build. See the cost section below.
What are the 10 Types of MVP?
The 10 types of MVP are landing page, explainer video, pre-order or crowdfunding, concierge, Wizard of Oz, piecemeal, single-feature, private beta, internal-first, and AI human-in-the-loop MVPs. They differ mainly in how much you build, how quickly you can test the idea, and which assumption you want to validate first.
#
MVP type
Best for testing
1
Landing page
Demand
2
Explainer video
Demand and clarity
3
Pre-order/crowdfunding
Demand and willingness to pay
4
Concierge
Value of the outcome
5
Wizard of Oz
Usage with a manual backend
6
Piecemeal
Workflow using existing tools
7
Single-feature
Repeat use of one workflow
8
Private beta
Retention and feedback
9
Internal-first
Fit with a real daily workflow
10
AI human-in-the-loop
Automation value and accuracy
Types 7 to 10 need working software. Teams building those often bring in MVP development services to scope the smallest build that answers the question.
10 Types of MVP With Real Startup Examples
Each type below follows one format: what it is, a real startup example, what to build, and where it breaks.
1. Landing Page MVP: How Buffer Tested Demand
A landing page MVP is a simple web page that describes your product and measures whether visitors take an action, such as joining a waitlist or choosing a price plan. It tests demand before you write product code.
How Buffer Used It?
Joel Gascoigne built a two-page site before building the product.
Page one explained the idea. A Plans and Pricing button led to a page saying was not ready, with an email field.
He later added a pricing page in between. Clicks showed which plan people chose and how keen they were.
Result: About 2.5 months after launch, Buffer had 500+ users, and around 4% of people upgraded to paid plans.
Typical Time and Cost
InApps puts a landing page MVP at 1 to 3 days and $0 to $2,000.
Build vs Fake
Build one page, one call to action, and basic analytics. Fake the product itself.
Where It Breaks
A bare email form measures curiosity, not intent. Gascoigne himself warns that asking for an email on page one wastes the chance to validate.
2. Explainer Video MVP: How Dropbox Proved Demand
An explainer video MVP is a short demo that shows how a product would work before it exists publicly. It tests whether people understand the idea and want it.
How Dropbox Used It
Drew Houston recorded a roughly three-minute screencast of his Dropbox prototype. The demo worked only on Windows, but it showed the core idea clearly.
According to TechCrunch, He aimed the video at the Digg audience and added about a dozen in-jokes for them. Within 24 hours, it had more than 10,000 Diggs.
Result: The beta waitlist grew from 5,000 to 75,000 people overnight.
Why It Worked: Few people understood cloud file sync at the time. Video fits best when the technology is hard to explain in text.
Typical Time and Cost
InApps puts a video MVP at 1 to 2 weeks and $500 to $5,000.
Build vs Fake
Build a tight script and a screen recording of your working prototype. Keep the video honest about what exists.
Where It Breaks
Views are not intent. Track signups and referrals, not play counts.
3. Pre-Order or Crowdfunding MVP: How Pebble Raised $10.3M
A pre-order MVP asks buyers to pay before the product ships. It is the strongest demand test because the signal is money, not interest.
How Pebble Used It
Pebble launched a Kickstarter campaign on April 11, 2012, with a $100,000 goal. Backers paid $115 for a watch.
According to a report, the campaign closed on May 18 with $10,266,845 from 68,929 backers. It was the most-funded Kickstarter project at the time.
Result: Traditional investors had passed on Pebble, so the campaign supplied both cash and proof of demand.
Build vs Fake
Build a working prototype, a demo video, and clear reward tiers. Fake nothing, because backers expect delivery.
Where It Breaks
Taking money creates delivery obligations. Pebble planned to ship in September 2012 and began shipping on January 23, 2013, after manufacturing difficulties.
Typical Time
The campaign itself ran just over five weeks, but the prototype and video came first. Budget for both.
Software founders often use paid waitlists or founding-member plans instead.
4. Concierge MVP: How Airbnb Doubled Early Revenue
A concierge MVP delivers your service by hand to a few customers, who know a person is doing the work. It tests whether the outcome is valuable before you automate anything.
How Airbnb Used It
According to CNBC, early on, Airbnb earned about $200 a week, according to co-founder Joe Gebbia. The founders flew to New York and found that host photos were poor.
They met hosts and uploaded better photos of themselves. Weekly revenue rose from $200 to $400.
Label Note: Roundups tag Airbnb as landing page, concierge or Wizard of Oz. The photo episode fits concierge because the founders delivered the service in person.
Build vs Fake
Build a checklist, a spreadsheet, and a clear promise. Skip the automation.
Where it Breaks
Manual work hides your real cost per customer. Log hours per customer from day one so you can price the automated version.
Keep the group small. Five to ten customers teach you more than fifty rushed ones.
5. Wizard of Oz MVP: How Zappos Tested Online Shoe Sales
A Wizard of Oz MVP looks automated to the customer while people do the work behind the scenes. It tests whether users will use the product before you build the engine.
How Zappos Used It
In 1999, Nick Swinmurn wanted to know if people would buy shoes online. He photographed shoes at local stores and listed them on a simple site.
When an order arrived, he bought the pair at full retail price and shipped it himself.
Result: Orders came in, which showed people would buy shoes online. Amazon acquired Zappos in 2009 for about $1.2 billion.
Label Note: Some roundups call this concierge. Customers saw a normal store, which makes it the Wizard of Oz.
Build vs Fake
Build the storefront and ordering flow. Fake inventory, warehousing, and fulfillment.
Where it Breaks
Manual fulfillment can lose money on every order. Swinmurn was essentially breaking even at best.
Set a cap on orders you will fulfill by hand before the test starts.
6. Piecemeal MVP: How Groupon Started With a Blog and Email
A piecemeal MVP combines existing tools, such as email, forms, and spreadsheets, to deliver a service without custom software. It tests whether the workflow works before you build a platform.
How Groupon Used It
Groupon’s first version was a WordPress blog where Andrew Mason posted sales announcements.
Mason has described emailing coupon PDFs with a script, including about 500 PDFs for a single day of sushi-coupon sales.
Result: Groupon reportedly reached about $1 billion in revenue within a couple of years.
Build vs Fake
Build nothing custom. Connect off-the-shelf tools and add no-code automation where manual steps pile up.
Where It Breaks
Manual glue fails at volume. Decide in advance how many orders you will handle by hand, then replace the busiest step first.
Typical Time and Cost
A piecemeal setup often takes one to four weeks and a few thousand dollars in tools and labor.
This is also where AI-powered workflow automation often replaces the first manual steps once volume grows.
7. Single-Feature MVP: How Instagram Cut Down to Photos
A single-feature MVP is a coded product that does one job well. It tests whether people use that one workflow again and again.
How Instagram Used It
Kevin Systrom first built Burbn, an app with check-ins, plans, and photo sharing. Beta users mostly shared photos.
Systrom and Mike Krieger scrapped Burbn and rebuilt around photos, with a post possible in as few as three clicks.
Result: According to TechCrunch, Instagram launched on October 6, 2010, and 25,000 users joined on day one.
The first version took about eight weeks to build.
Build vs Fake
Build one core loop, one user role, and basic analytics. Cut every feature that does not support that loop.
For SaaS products, scope one workflow, one user role, and one pricing plan first. Technource’s SaaS development services typically deliver a SaaS MVP in 8 to 12 weeks.
Typical Cost
Technource’s simple MVP tier runs $8,000 to $15,000, depending on scope.
Where it Breaks
Feature creep. Burbn bundled several features, so the signal stayed buried until the founders studied usage.
8. Private Beta MVP: How Duolingo Built a Waitlist
A private beta MVP releases a working product to a limited, invited group. It tests retention and feedback before a public launch.
How Duolingo Used It
Duolingo opened a private beta on November 27, 2011. Its waiting list passed 300,000 people.
The public launch came on June 19, 2012, when the waiting list had grown to about 500,000.
Result: The invite queue gave Duolingo a steady flow of testers and about seven months to improve the product before opening to everyone.
Build vs Fake
Build the core loop, an invite system, a feedback channel, and analytics. Delay scale features such as advanced billing.
Where it Breaks
A long waitlist is not retention. Measure week-one and week-four return rates, and invite users in small waves so you can fix issues before the next wave.
B2B Variant
B2B teams often run a paid pilot or a design-partner program instead. Userpilot lists both as functional MVP formats.
9. Internal-First MVP: How Slack Started as a Team Tool
An internal-first MVP is a tool your own team uses before you release it to customers. It tests whether the product holds up in a real daily workflow.
How Slack Used It
The team at Tiny Speck built an internal chat tool while developing a game called Glitch. The game failed, but the team saw how useful the tool was and turned it into Slack.
Result: On the first day of the preview release, 8,000 people requested invitations.
Best Fit
Internal-first suits products that solve a problem your team feels every day, such as workflow tools and dashboards.
Build vs Fake
Build for your team’s real daily use. Add admin controls, billing, and onboarding only after outsiders ask for them.
Log every workaround your team invents. Each one points to a missing feature or a wrong assumption.
Where It Breaks
Your team is not your market. Internal users know the context and forgive rough edges, so confirm demand with outside users next.
10. AI Human-in-the-Loop MVP: How X.ai Scheduled Meetings
An AI human-in-the-loop MVP automates a workflow with AI while people review or complete the hard cases. It tests whether the automation is valuable before you invest in full accuracy.
How X.ai Used It
X.ai launched Amy, an AI assistant that scheduled meetings by email, in 2014. Bloomberg reported that human AI trainers checked parts of almost all incoming emails.
The company said trainers verified the vast majority of email content so the system could improve.
Result: X.ai processed millions of meeting requests with high accuracy, though high human operational costs eventually led to its acquisition in 2021.
Why It Works
Customers get the outcome now. You collect labeled data on every correction, which shows what to automate next.
Build vs Fake
Build the workflow, the AI step, and a review queue. Keep humans on every output at first, then reduce review as accuracy rises.
Track two numbers: the share of outputs humans edit, and the time each review takes.
Where It Breaks
Hidden humans erode trust. In 2017, Expensify faced criticism when customers’ receipts appeared on Amazon Mechanical Turk.
Disclose human review in your terms, limit data access, and sign NDAs with reviewers.
Too many MVP options? We’ll help you choose the one that fits your idea.
Pick the MVP type that tests your riskiest assumption at the lowest cost. If you are unsure anyone wants the product, test demand first, then usage, then willingness to pay.
The table adapts a demand, behavior, and payment framework from Userpilot and adds an accuracy test for AI products.
What you are unsure about
Best MVP types
Strong signal
Weak signal
Demand: Do People Want It?
Landing page, explainer video, pre-order
Prepayment, referrals, repeat visits
Email capture alone, video views
Usage: Will They Use It?
Concierge, Wizard of Oz, piecemeal, single-feature, private beta, internal-first
Repeat unprompted use, completed core loop
One-time logins, demo attendance
Payment: Will They Pay?
Pre-order, paid pilot, paid beta plan
Signed contract, paid pre-order
Verbal yes, “we would consider it”
Accuracy: Can AI do the Job?
AI human-in-the-loop, Wizard of Oz
Low human edit rate, steady accuracy
Polished demo on hand-picked inputs
Use these quick rules when the table feels abstract.
No customers yet: run a landing page or video test.
Service business going digital: start with a concierge.
Physical or hardware product: use pre-orders.
Complex backend, unproven demand: use Wizard of Oz.
Proven demand, ready to build: ship a single-feature MVP.
B2B workflow tool: go internal-first, then a paid pilot.
AI workflow: add human review on every output.
The cost of being wrong rises fast. Write the pass or fail threshold before you start. InApps cites 5% or more of visitors clicking after seeing pricing as healthy, and under 2% as a warning.
Technource’s Recommendation: Validate the highest-risk workflow before committing to a fully coded MVP. In our MVP projects, the cheapest useful test is usually the one that gives the clearest evidence about the assumption most likely to make the product fail.
Not sure what to build first? We’ll identify the riskiest assumption and test it.
Run an MVP test in five steps: state the hypothesis, choose the type, set a pass or fail threshold, run the test for a fixed window, then decide. Once you know what to validate and which MVP type fits, building an MVP becomes the next step. InApps puts a full pre-build validation sequence at under $500 and 2 to 4 weeks.
Step 1: State the Hypothesis
Write one sentence: we believe this customer will take this action because of this reason.
Name the number that would prove you right, such as 5% of visitors choosing a paid plan.
What Can Go Wrong: Vague hypotheses produce vague results. If you cannot write the sentence, you are not ready to test.
Step 2: Choose the MVP Type
Match the type to your riskiest assumption using the table above. Pick the cheapest type that can produce a strong signal.
What Can Go Wrong: Teams pick the format that is easiest to build, then bend the hypothesis to fit what it measures.
Step 3: Set the Pass or Fail Threshold
Write the threshold, the sample size and the end date before launch. Share them with your team and investors.
What Can Go Wrong: Teams move the goalposts after the results arrive. Lock the numbers in writing.
Step 4: Run the Test for a Fixed Window
Run it for two to four weeks and log every customer conversation. Keep changes to a minimum while the test runs.
What Can Go Wrong: Small samples mislead. A handful of friendly users can mimic demand, so recruit people who do not know you.
Step 5: Decide whether to persevere, pivot, or stop
Compare results with the threshold. Persevere if you pass, pivot if usage differs from your plan, and stop if demand is absent.
What Can Go Wrong: Sunk-cost bias. A failed test is a cheap result, not a reason to run a bigger version of the same test.
How Much Does an MVP Cost?
A simple coded MVP costs $8,000 to $15,000 at Technource, mid-complexity MVP costs $20,000 to $30,000 while complex products run $30,000 to $50,000 or more. No-code MVP costs around $5,000 to $7,000. The MVP development cost depends on factors such as the product’s complexity, number of workflows, integrations, and build approach.
Build level
Typical cost
What you get
Simple MVP
$8,000–$15,000
One core workflow with basic analytics
Mid-complexity MVP
$20,000–$30,000
Several workflows, roles and integrations
Complex MVP
$30,000–$50,000+
Multi-role platform, deep integrations or AI
Purrweb reports a wider market range of $20,000 to $80,000, depending on platform, feature complexity, and team location. (Source: Purrweb)
Timelines follow scope. A SaaS MVP typically takes 8 to 12 weeks, and a mid-complexity SaaS product 3 to 6 months.
Choose the cheapest MVP type that answers your question. A $2,000 landing test can save a $30,000 build.
Technource’s Take on MVP Project Costs: MVP cost is driven more by the validation approach and product complexity than by the number of features alone. A focused MVP that proves one core workflow can be significantly cheaper than building several workflows before knowing which one customers actually need.
Worried about overspending before you validate your idea? Let’s scope the right MVP first.
The most common MVP mistakes are testing the wrong assumption, building too much, and counting vanity signals as proof. Understanding why most MVPs fail can help teams avoid wasting budget without producing useful evidence.
Mistake
What it looks like
Fix
Testing the wrong assumption
A landing page tests demand when pricing is the real risk
Name the riskiest assumption first
Building too much
Ten features and no clear core loop
Cut to one workflow
Counting vanity signals
5,000 email signups and no payments
Track prepayment or repeat use
Skipping a pass or fail rule
Results get interpreted after the fact
Set thresholds before launch
Hiding the manual work
Fake automation with no disclosure plan
Disclose human review and protect data
Ignoring cost per customer
Manual tests look cheap at 10 users
Log hours per customer
Userpilot’s example shows the trap. A page with 5,000 signups looks like demand, yet says little about willingness to pay.
Marty Cagan also separates an MVP test from a real product. Mixing the two causes much of the confusion.
What Happens When Teams Skip the MVP?
Teams that skip low-cost validation can spend an entire budget before learning whether customers want the product. Quibi shows the extreme: it raised $1.75 billion and shut down six months after launch.
The service struggled to reach viewers despite a 90-day free trial.
Executives also pointed to the pandemic, which kept people at home in front of TVs instead of phones.
We cannot know what a small test would have shown. We do know the price of learning at launch.
Compare that with Buffer, which learned about pricing from a two-page site. Same question, a fraction of the cost.
How Technource Helps You Choose and Build the Right MVP
Technource is an AI-powered product engineering company with 14+ years of experience and 1,000+ projects delivered.
We start every MVP with discovery, not code. Discovery is where we rank your assumptions and choose the cheapest test that answers the biggest one.
Technource’s Approach to MVP Development
During discovery, we rank your core assumptions and risks to choose the standard, lowest-cost MVP model that tests your biggest questions with real users.
Our 6-Step SaaS development process guides your project from concept to launch:
1. Discovery & Planning: Uncover key risks, rank assumptions, and define the right MVP type.
2. Product Design: Scope the smallest, user-focused product built around a single core workflow.
3. Architecture & Development: Build for immediate validation while keeping the foundation ready for future scale.
4. Cloud Deployment: Set up reliable infrastructure and deploy securely.
6. Ongoing Support & Scaling: Add deeper integrations and automation as product-market fit is proven.
Key Pillars of Our MVP Framework
Our MVP framework is designed to validate the core product idea before significant development investment. These principles help keep the first release focused, scalable, secure, and aligned with real user needs.
Discovery Before Code: Focus on testing high-risk assumptions before writing a single line of software.
Narrow Scope: SaaS MVPs usually ship in 8 to 12 weeks by focusing on the primary value proposition.
Security Built In: HIPAA, SOC 2, and GDPR compliance standards are applied from day one where applicable.
Clear Ownership: You retain 100% ownership of all source code and intellectual property upon delivery.
How Technource Helped Telepath Achieve 65% Faster E-Prescribing Approvals With a Scalable SaaS Platform
We built Telepath, a scalable SaaS pharmacy platform for healthcare organizations that needed branded portals, e-prescriptions, medicine ordering, telehealth appointments, and multi-tenant organization management. Technource solved this by building a multi-tenant platform that allowed different organizations to operate independent branded pharmacy portals from a shared system.
The platform used a scalable architecture with custom subdomains, flexible onboarding, and automated cart abandonment workflows. The technology stack included React.js, AWS S3, DoseSpot, Agora, Carepoint & TransitionRx, Easypost, and Paytheory to support e-prescribing, telehealth, pharmacy coordination, shipping, and payments.
Measurable Result
65% faster e-prescribing approvals
90% more transparent onboarding through flexible flows
Customizable pharmacy setup for different healthcare organizations
Automated cart recovery workflows to help improve purchase conversions
Connected pharmacy and shipping workflows through Carepoint, TransitionRx, and Easypost integrations
The lesson for MVP planning is straightforward: validate the core workflow first, but design the architecture so a validated workflow can scale without requiring the product to be rebuilt from scratch.
Future Trends in MVP Development
Three shifts are changing how teams choose MVP types in 2026.
AI prototyping lowers build cost. Tools such as v0, Bolt, Lovable, Cursor, and Replit Agent have cut the cost of building most functional MVP types to about a weekend. The bottleneck moves from building to picking the right test.
The label count keeps growing. MLP, MMP, SLC, and RAT each argue for a different meaning of viable.
Choosing by hypothesis keeps you out of the naming debate.
Disclosure becomes a baseline. The X.ai and Expensify stories show how fast trust drops when human work is hidden. We expect customers and enterprise buyers to ask how much of an AI product is automated.
Conclusion
The right type of MVP depends on one question: what are you least sure about?
1. Match the MVP type to your riskiest assumption, not to what is easiest to build.
2. Set a pass or fail threshold before you launch the test.
3. Choose the cheapest type that answers your question, and move to code only when the signal is strong.
Your next step: write your riskiest assumption in one sentence, then pick the matching type from the table above. Once the signal is strong enough to move into development, an experienced MVP development company can help turn the validated concept into a functional product.
Have a product idea but no clear path to launch? Let’s turn it into a focused MVP.
The main types of MVP are landing page, explainer video, pre-order or crowdfunding, concierge, Wizard of Oz, piecemeal, single-feature, private beta, internal-first, and AI human-in-the-loop. Each type tests a different assumption, such as demand, usage, willingness to pay, workflow value, or AI accuracy, before you invest in a larger product build.
Dropbox is one of the most cited MVP examples. Its roughly three-minute demo video helped grow the beta waitlist from 5,000 to 75,000 people overnight. The approach worked because cloud file synchronization was difficult to explain in text, while a short video could demonstrate the core idea before the product was publicly available.
A concierge MVP delivers a service manually to a small group of customers who know that a person is doing the work. It tests whether the outcome is valuable before you automate anything. The article uses Airbnb as an example: its founders manually improved host photos, and early weekly revenue increased from about $200 to $400.
In a concierge MVP, customers know that a person delivers the service manually. In a Wizard of Oz MVP, the service looks automated to customers while people perform the work behind the scenes. Both approaches test usage before full development, but the key difference is whether customers know that the process is manual.
A simple coded MVP costs $8,000 to $15,000 at Technource; a mid-level MVP costs around $20,000 to $30,000, while a complex MVP costs $30,000 to $50,000 or more. The broader market range can be higher depending on the platform, feature complexity, and team location.
A landing page MVP can take 1 to 3 days, while a coded SaaS MVP typically takes 8 to 12 weeks. A mid-complexity SaaS product can take 3 to 6 months. The actual timeline depends on scope and how clearly the requirements are defined before development begins.
A prototype shows how a product could look or work, usually without real users or a working backend. An MVP is a live test with real users that produces evidence about demand or usage. In simple terms, a prototype explores how the product could work, while an MVP tests whether people will use or pay for it.
An MVP is the smallest experiment that tests a hypothesis about whether something is worth building. In contrast, an MMP, or Minimum Marketable Product, is the smallest version you can sell to paying customers without apology. The article distinguishes them by purpose: an MVP validates the product idea, while an MMP is ready for paying customers.
AI ConsultingStrategic AI Roadmaps
