What is an MVP? How to build a minimum viable product
An MVP (minimum viable product) is a first release that tests whether an idea really works, using the least effort possible. This guide explains how it differs from a prototype and how to choose features. It also covers the build steps and the metrics to watch.
What is an MVP?
According to Eric Ries, who popularised the term, an MVP is the version of a new product that lets a team collect the maximum amount of validated learning about customers with the least effort. His original article adds a useful warning. Despite the name, he writes, it is not about creating minimal products.
In other words, the real output is learning rather than software. For example, “Clinics will use this report every week” is an assumption. A first release tests that assumption without months of development.
Why does an MVP work?
The most expensive mistake is building a complete product that nobody wants. A March 2026 analysis by CB Insights examined 431 venture-backed companies that have shut down since 2023. Of the 385 with a known cause, 70% ran out of capital. In addition, 43% had poor product-market fit.
Because companies could cite several reasons, the percentages add up to more than 100. The sample also covers venture-backed companies only. Still, the direction is clear: spending the whole budget before you see a market signal is a serious risk. An MVP lets you test that risk with a small part of the budget.
MVP vs prototype vs full product
| Criterion | Prototype | MVP | Full product |
|---|---|---|---|
| Purpose | Show the idea and the flow | Test an assumption with real use | Serve the wider market |
| Users | The team and a few testers | A real but limited group | The whole target audience |
| Working software | Often none | Yes, narrow in scope | Yes, broad in scope |
| Can it take payment? | No | Usually yes | Yes |
For an MVP, narrow scope does not mean low quality. The few features you ship must work reliably. Otherwise, you cannot tell whether users rejected the idea or just the faulty software.
Before you write code: types of MVP
- Explainer video: A short video and a waiting list measure demand.
- Landing page: It collects sign-ups or pre-orders before the product exists.
- Manual service: The customer sees a finished service, while the team does the work by hand.
- Single-feature product: Narrow working software does the most valuable job.
For example, a team can publish a short demo video before it builds the product. It then counts the people who join the waiting list. As a result, it sees demand before it invests heavily in infrastructure.
Which features belong in the first release?
First, write one sentence: “When [user] faces [problem], this product gives them [result].” Then ask one question about each feature: does the sentence still hold without it? If it does, the feature waits.
| Group | Meaning | Example |
|---|---|---|
| Must have | The product fails without it | Creating an appointment |
| Useful | Adds value, but it can wait | Calendar export |
| Later | Rests on assumptions for now | Advanced reports |
How to build an MVP in 6 steps
- Write down the assumption: Turn your riskiest belief into a measurable sentence.
- Narrow the audience: Pick one group you can reach instead of “everyone”.
- Set a success threshold: Write the number before you build, so you judge the result honestly.
- Cut the scope: Use the table above to reduce the list to must-haves.
- Build and release: Next, start real use with your first users.
- Measure and decide: Finally, choose to continue, change direction or stop.
Timing depends on scope, although a first release that takes many months often signals a scope that is too wide. If your product will serve many customers, read our SaaS guide. If it must run on phones, our mobile app guide will help.
Which metrics should you track?
- Activation: How many sign-ups completed the core task at least once?
- Retention: Do users come back after a week or a month?
- Willingness to pay: How many continue when you ask for a fee?
- Qualitative feedback: How disappointed would users be if the product vanished?
Total sign-ups and downloads, by contrast, can mislead. These numbers show interest rather than value. For this reason, base your decision on returning users.
4 common mistakes
- Inflating the scope: Each “let’s add this too” delays learning and drains budget.
- Sacrificing quality: A broken product tells you nothing useful about the idea.
- Asking friends only: People close to you tend to be polite, but they rarely pay.
- Ignoring architecture entirely: Shortcuts are fine, as long as you take them on purpose.
Building an MVP with Coratlas
At Coratlas, we split projects into phases and aim to deliver the first working version early. First, we use a free initial consultation to clarify your assumption and scope together. Then we build the first release on a foundation that can grow later.
To plan your budget, see our software development cost guide. For service details, visit our custom software development and mobile app development pages.
Frequently asked questions
What does MVP stand for?
It stands for “minimum viable product”. In software and startups, the term never means “most valuable player”.
Do only startups build an MVP?
No. Established companies also trial a new internal tool or service with a limited team. That way, they collect real usage data before a company-wide rollout.
Can you sell a first release?
Yes, and selling it gives the strongest signal. A paying user tells you far more than an interested one.
What if the results are poor?
First, separate the cause: is it the wrong audience, the wrong feature or the wrong idea? Then change direction or stop. Learning cheaply is the whole point of an MVP.
This article is for general information only and is not legal, financial or medical advice. Consult a qualified professional about your own situation.