A minimum viable product (MVP) is the simplest version of a product or service that lets you test your core assumption with real customers. It's not a cheap version of your full vision. It's an experiment designed to answer one question, usually "Will people use this and pay for it?", with the least time and money. Done well, an MVP tells you whether to build more, change direction or stop.
This guide is for founders and owners considering a new product, app, service line or offer. You'll learn what counts as an MVP, the main types (many need no code at all), how to set success criteria before you start, a worked example with real numbers, and a decision rule for reading the results.
What an MVP is, and what it isn't
The key word is viable. An MVP has to deliver enough real value that a customer would use it, and ideally pay for it. The key word people forget is minimum: it should include only what's needed to test your riskiest assumption.
An MVP is:
- A test of whether customers want the outcome you're promising
- Something real people use, not a questionnaire about whether they might
- Designed around a specific question with a measurable answer
An MVP isn't:
- A buggy version of the full product
- A prototype only your friends see
- Version one of a roadmap you've already committed to building regardless of results
MVPs aren't just for software. A bakery testing a catering line, a consultant testing a new package or a gym testing a new class format can all use the same thinking.
Types of MVPs, from cheapest to most involved
| Type | How it works | Best for testing | Watch out for |
|---|---|---|---|
| Landing page or pre-order | Describe the offer and ask for sign-ups, deposits or pre-orders | Whether the pitch and price attract interest | Sign-ups aren't purchases; deposits are stronger evidence |
| Concierge | Deliver the service manually and personally to a few customers | Whether the outcome is valuable, and what customers really need | Doesn't test whether it can scale |
| Behind-the-curtain | Customers see a product-like experience, but you do the work by hand in the background | Whether customers use it the way you expect | Be honest; don't mislead customers about how it works |
| Single-feature | Build only the one feature that delivers the core value | Whether that core feature alone is enough | Resisting the urge to add "just one more thing" |
| Pilot or pop-up | Run a limited version for a set time, place or customer group | Real demand and operations under realistic conditions | Results may not generalize beyond the pilot group |
Pick the cheapest type that can genuinely answer your question. If the question is "Will anyone pay $99 a month?", you may not need to build anything.
How to build an MVP, step by step
- Write down your assumptions. List everything that must be true for the business to work: customers have this problem, they'll pay this much, they'll use it weekly, you can deliver it at this cost.
- Pick the riskiest one. Which assumption, if wrong, kills the idea? Test that first.
- Set success criteria in advance. Write specific thresholds before you start, like "At least 6 of 10 pilot users still active after 8 weeks." Deciding afterward invites wishful thinking.
- Choose the MVP type that tests that assumption fastest and cheapest.
- Recruit real target customers, not friends and family. Aim for 10 to 30, depending on the offer.
- Run it for a fixed period, long enough to see real behavior, often four to twelve weeks.
- Measure behavior, not opinions. Usage, retention, payments and referrals count more than "I love it."
- Talk to every user at the end: what they valued, what they ignored, what they'd pay.
- Decide: build more, change direction or stop (see the decision rule below).
Before building an MVP, some basic research on the market saves time. Our guide on market research without hiring a firm covers the groundwork.
Worked example: testing a crew-scheduling tool before building it
Suppose a hypothetical founder wants to build scheduling software for small landscaping companies. A developer quotes $60,000 and six months for a full product. The founder's riskiest assumption: landscaping owners will pay $99 a month to stop scheduling crews by text message.
Instead of building, the founder runs a concierge MVP. For 10 landscaping companies, she takes their job lists each Sunday, builds the crew schedules herself in a shared spreadsheet, and sends each crew its route by text. Total cost: about $1,500 in her time and simple tools, over six weeks of setup plus an eight-week pilot.
Success criteria set in advance:
- At least 6 of 10 companies still actively using the service after 8 weeks
- At least 4 of 10 agreeing to pay $99 a month to continue
Results:
- 7 of 10 still active after 8 weeks: retention criterion met
- 3 of 10 willing to pay $99 a month: pricing criterion missed
- 5 of 10 willing to pay $59 a month
Now run the numbers on the original plan:
- Monthly revenue at $99: 3 × $99 = $297
- Monthly revenue at $59: 5 × $59 = $295
- Customer-months needed to recoup a $60,000 build at $59: $60,000 ÷ $59 ≈ 1,017. That's, for example, about 85 paying customers for a full year.
- At $99: $60,000 ÷ $99 ≈ 606 customer-months, or about 51 customers for a year
The founder learned three things for $1,500 instead of $60,000. The problem is real (70% stayed). The price is too high for most of this market. And interviews revealed that owners valued the rain-day rescheduling far more than the weekly schedule itself. Her next MVP tests a smaller, cheaper product focused on that one feature.
How to read the results: persevere, pivot or stop
Use your pre-set criteria and this rule:
- Persevere if you met or beat your key criteria. Build the next most important piece and set new criteria for the next test.
- Pivot if some criteria were met and others weren't, especially if users valued something unexpected. Change one major variable, such as price, customer segment or core feature, and test again.
- Stop if usage and willingness to pay were both weak, and interviews don't point to a promising alternative. Stopping early is a success: you saved the cost of building something nobody wanted.
Over several rounds, you're looking for signs of product-market fit: customers who keep using the product, pay without heavy persuasion and tell others about it.
Common MVP mistakes
- Building too much. Adding features "so it's not embarrassing" delays learning and costs money. If a feature doesn't help test your riskiest assumption, cut it.
- Testing with friends and family. They'll be kind, not honest. Recruit people who match your real target customer.
- Measuring opinions instead of behavior. "I'd definitely use that" costs nothing to say. Track usage, retention and payment.
- Not setting success criteria upfront. Without them, any result can be spun as a win. Write numbers down before you start.
- Treating a failed test as a failure. An MVP that disproves an assumption cheaply has done its job. Learn from it and adjust.
- Confusing an MVP with a launch. The goal is learning, not revenue. Keep scope small so you can change direction quickly.
If you're still at the idea stage, start with our guide to validating a business idea, which covers the conversations and tests that come before an MVP.
Where AI can help
AI tools can shorten the build-and-learn cycle. An assistant can help you list and rank your assumptions, draft a landing page or pre-order page, write recruiting messages for pilot customers, and prepare interview questions that avoid leading the witness. After the test, you can paste in interview notes and ask it to summarize common themes and surprising comments. For simple software ideas, AI coding tools can speed up building a basic prototype.
Don't let AI stand in for customers. It can guess what people might want, but only real users' behavior tells you what they'll pay for. Review any AI-built prototype for security and data handling before real customers use it.
Frequently asked questions
How much does an MVP cost?
It can range from nearly nothing for a landing page or concierge test to tens of thousands for a software product. Start with the cheapest version that can answer your riskiest question. Many good MVPs cost more in time than in money.
How long should an MVP test run?
Long enough to see real behavior, including whether people keep using it after the novelty wears off. For many products and services, four to twelve weeks is a reasonable range. Set the timeline before you start.
How many users do I need for an MVP?
For early tests, 10 to 30 well-chosen users often reveal the most important patterns. You're looking for clear signals and insights, not statistical proof. Larger tests make sense later, once you're refining.
Should I charge for an MVP?
Usually yes, if you can. Payment is the strongest evidence that you've created value. Even a discounted pilot price tells you far more than free usage, since free products attract people who would never pay.
Key takeaways
- An MVP is an experiment to test your riskiest assumption with real customers, as cheaply as possible.
- Many effective MVPs need no code: landing pages, concierge service and pilots all work.
- Set specific success criteria before you start, and measure behavior, not opinions.
- A cheap test that disproves an assumption can save many times its cost.
- After each test, decide to persevere, pivot or stop, based on your pre-set criteria.
Comments
Post a Comment