An MVP, or minimum viable product, is the smallest version of a product that real customers will use, and ideally pay for, so you can learn whether the idea works. It isn't a cheap or unfinished version of your full vision. It's an experiment with a clear question, built with just enough quality that the answer can be trusted.
What does "minimum viable" actually mean?
"Minimum" means the fewest features needed to deliver one core outcome. "Viable" means it genuinely works for the people using it: reliable, usable and good enough that their behaviour tells you something real.
Founders tend to over-focus on one word. Lean too hard on "minimum" and you ship something so thin that users leave for reasons unrelated to your idea, so you learn nothing. Lean too hard on "viable" and you spend a year polishing before anyone sees it.
The point of an MVP is learning, not launching. Every feature should exist because it helps answer the question "will this specific customer use and pay for this?"
What is an MVP not?
An MVP is often confused with a prototype, a beta or a first full release. They serve different purposes, and mixing them up is a common source of wasted budget.
| Thing | What it is | Who uses it | What it proves |
|---|---|---|---|
| Mockup or prototype | Clickable screens with no real functionality | Founders, investors, test users in sessions | Whether people understand the concept and flow |
| Proof of concept | A technical experiment | The development team | Whether something is technically possible |
| MVP | A working product with one core job done well | Real early customers, in real conditions | Whether customers will adopt and pay |
| Beta | A broader product being hardened before general release | A wider group of users | Whether the product is stable and complete enough |
| Version 1.0 | The first full public release | The market | Whether you can acquire and keep customers at scale |
If you need to convince an investor that a flow makes sense, a prototype may be enough. If you need to know whether customers pay, only an MVP or a pre-sale will tell you.
Which type of MVP fits your idea?
Not every MVP involves custom software. Some of the most useful ones need almost no code, and choosing the right type can save months.
| MVP type | How it works | Relative cost | Best for testing |
|---|---|---|---|
| Landing page (smoke test) | Describe the product and ask people to sign up, pre-order or book a demo | Very low | Demand and messaging |
| Concierge | You deliver the outcome manually for a few customers | Low (mostly your time) | Whether the outcome is valuable enough to pay for |
| "Wizard of Oz" | Customers see a product interface, but humans do the work behind it | Low to moderate | Whether the experience works before automating it |
| No-code build | Assembled from no-code tools and connectors | Low to moderate | Simple workflows and early retention |
| Single-feature custom build | Custom software that does one job end to end | Moderate (typically US$15k–50k for a full MVP) | Adoption, retention and willingness to pay at real usage |
A sensible path for many ideas runs left to right: a landing page proves interest, a concierge test proves value, and a custom build follows once people are paying. You can skip steps when the risk is technical rather than commercial, for example when the hard part is whether the software can do something at all.
How do you decide what goes into an MVP?
Define one user, one job and one success measure, then include only what that job needs. Everything else goes on a "later" list.
Work through it in order:
- Pick the first user. Not "businesses" but "the office manager at a three-location dental group". Different users want different things, and serving two at once doubles scope.
- Name the one job. What outcome do they hire the product for? "Send accurate quotes in under five minutes" is a job. "Manage the business" is not.
- Map the shortest path to that outcome. Write the steps the user takes from sign-up to result. Each step becomes a screen or feature.
- Set the success measure. For example, a set number of weekly active users after a month, or a target number of paying accounts. Decide it before building so results can't be reinterpreted later.
- Apply the refusal test. For every proposed feature, ask: would the user refuse to use or pay for the product without it? If not, it waits.
Plumbing still counts. Sign-up, login, basic security, payment collection and a simple way for you to help customers are part of "viable" even though they aren't exciting.
Where do founders waste money on MVPs?
Most wasted MVP spend comes from building for imagined future users instead of the first real ones. These are the patterns to avoid:
- Building for scale you don't have. Architecture for a million users when you have none. Build sensibly, but solve scale when usage demands it.
- Native apps on every platform at once. iOS, Android and web together means three platforms to design, build and test. Start with one; a responsive web app or a progressive web app often covers early needs at lower cost.
- Multiple user roles in version one. Each role adds screens, permissions and testing.
- Bespoke design systems. A clean interface built on a proven component library looks professional and costs far less than custom-designing every element.
- Admin panels nobody needs yet. Early on, founders can manage edge cases by hand or directly in a simple back office.
- Integrations "because customers will want them". Add each integration when a paying customer asks for it.
- Skipping discovery. Unclear requirements are the most expensive thing in software, because every misunderstanding becomes rework.
Spending less is not the same as wasting less. A rushed, buggy MVP that loses early users wastes the whole budget, however small it was.
How much does an MVP cost and how long does it take?
A custom-built web app or SaaS MVP typically costs US$15,000–50,000, ₹4–12 lakh in India or AUD 25,000–80,000 in Australia, and takes about 8–16 weeks. These are typical market ranges; scope decides where you fall.
The biggest levers are the number of user roles, integrations, payments, AI features and whether you need a mobile app. A cross-platform mobile app MVP, for comparison, usually takes 10–20 weeks. Our detailed guide to how much it costs to build an MVP in 2026 breaks the numbers down, and our article on realistic custom software timelines explains what stretches or shortens a schedule.
What happens after the MVP launches?
After launch, the job is to measure behaviour, talk to users and decide whether to persevere, adjust or stop. The MVP's value is the decision it lets you make.
Watch three signals closely:
- Activation: do new users reach the core outcome in their first session or week?
- Retention: do they come back without being chased?
- Willingness to pay: do they convert, renew or ask about pricing?
If those signals are strong, invest in the features retained users ask for most. If they're weak, change one thing at a time (the customer, the job or the message) rather than adding more features. Also budget for upkeep: maintenance typically runs at about 15–25% of the build cost per year.
For the full journey from validated idea to paying customers, read our guide on how to build a SaaS product in 2026.
Frequently asked questions
Is an MVP the same as a prototype?
No. A prototype shows how a product might look and flow, usually without real functionality. An MVP is a working product used by real customers in real conditions, which is why it can test whether people will adopt and pay.
Can an MVP be built without code?
Yes. Landing-page tests, concierge services and no-code builds are all valid MVPs, and they are often the cheapest way to test demand. Custom code makes sense when the idea is validated or when the product needs logic, performance or data control that no-code tools can't provide.
How many features should an MVP have?
As few as possible to deliver one core outcome end to end, plus essentials like login, security and payment. There's no magic number. If you can't explain why a feature is needed for the first user's core job, leave it out.
Should I charge for my MVP?
Usually, yes. Payment is the strongest evidence of value, and paying customers give more honest feedback than free users. A founding-customer discount rewards early adopters while still testing willingness to pay.
What if my MVP fails?
Then it has done its job by saving you from a much bigger investment. Look at where it failed (wrong customer, wrong problem, wrong message or poor execution) and decide whether one change is worth testing. Many successful products began as a different idea that an MVP disproved.
Scope your MVP before you spend
The cheapest MVP is the one scoped clearly before development starts. If you have an idea and a target customer, a short discovery session will turn it into a feature list, timeline and fixed price. Book a discovery call to scope your MVP.