"MVP" is one of the most used and most misunderstood terms in product development. Some people hear it as "a cheap first version". Others treat it as "the full product, minus a few features". Neither description helps, and both lead to projects that spend too much, learn too little and launch something nobody is sure about.
A minimum viable product is simpler and more useful than either idea. It is the smallest release that lets you test whether your most important assumption is true, with real users, using real behaviour. This guide explains what that means in practice: how to decide what goes in, how to build it, what it costs and what to do next. We have also written about the decision from the other side in MVP vs full product: what to build first, and this article goes deeper on the how.
What an MVP actually is
An MVP has three characteristics.
- It is minimal. It contains only what is needed to test the core idea.
- It is viable. It works well enough that real people can use it for its purpose. A broken prototype tests patience, not your idea.
- It is a product. It is something users can try, not a slide deck, however polished.
The purpose matters more than the size. An MVP exists to answer a question, for example: "Will small clinics pay to replace paper booking?" or "Will customers reorder through an app?" If you cannot state the question, you do not yet know what to build.
What an MVP is not
- Not a prototype. A prototype shows how something could work, often with fake data. An MVP really works, even if narrowly.
- Not a buggy product. Minimal features are acceptable; unreliable ones are not.
- Not the whole roadmap, reduced. It is a different thing: a test, not a scaled-down launch.
- Not a one-time event. It begins a cycle of build, measure and learn.
Step 1: Name the riskiest assumption
Every product idea rests on beliefs that might be wrong. Common ones are:
- People have this problem and care enough to fix it.
- They will pay for our solution.
- They will change their current habits.
- We can reach them at a reasonable cost.
- We can deliver the service in the way we imagine.
List yours, then pick the one that would end the idea if it turned out false. That is your riskiest assumption, and the MVP should be designed to test it first. It is often about demand, not technology.
Step 2: Define the core user journey
Next, describe the single journey a user takes to get value. Write it as a short story: who the user is, what they want, what they do in the product and what they get. For a booking product, it might be: choose a service, pick a time, receive a confirmation.
Everything that supports this journey is a candidate for the MVP. Everything else goes on a "later" list. The discipline of cutting is the hardest and most valuable part. Useful questions:
- If this feature did not exist for the first hundred users, what would happen?
- Could a manual process, an email or a spreadsheet cover it temporarily?
- Does this feature help test the riskiest assumption?
If the answer to the last question is no, it probably waits.
Step 3: Choose the lightest version that can test the idea
There is a ladder of MVP types, from cheapest to most expensive. Start as low as your question allows.
| Type | What it is | Good for testing | Typical effort |
|---|---|---|---|
| Landing page | A page describing the offer with a sign-up | Interest and demand | Days |
| Clickable prototype | Designed screens linked together | Usability and early feedback | 2 to 4 weeks |
| Concierge MVP | You deliver the service manually behind a simple front end | Whether people value the outcome | Weeks |
| Single-feature product | One core feature, built properly | Whether people use and pay for it | 6 to 12 weeks |
| Working product | A coherent set of core features on web or mobile | The business model in real conditions | 3 to 5 months |
Many teams jump straight to the bottom of the table when a cheaper rung would answer their question. A landing page or prototype costs little and can save you from building the wrong thing.
Step 4: Decide what to build, and what not to
For the version you build, apply a simple rule: include only what a user needs to complete the core journey, plus what you need to learn from it.
Usually include:
- Sign-up and login (using a proven service where possible)
- The core feature, working reliably
- A way to contact you for support
- Basic analytics so you can see what users do
- A simple admin view so you can manage what is happening
Usually leave for later:
- Advanced settings and profile options
- Social features and sharing
- Elaborate dashboards and reports
- Multiple languages and currencies
- Complex roles and permissions
- Polish on rarely used screens
The "later" list is not a graveyard. It is a record of good ideas that will be prioritised once you know what users actually need.
Step 5: Choose the platform
Where you launch affects cost and speed.
- Web first is usually fastest and cheapest to build and to change, and needs no store approval.
- Mobile first makes sense when the product depends on the phone: camera, location, notifications or daily habits.
- Cross-platform mobile lets one codebase serve iOS and Android. We compare the main options in Flutter vs React Native, and our MVP development page explains how we approach first releases.
If you are unsure whether to start on web, mobile or desktop, read web app vs mobile app vs desktop app, which walks through the decision.
Step 6: Build in short cycles
An MVP should be built the way it will be used: in small steps, with feedback. A healthy rhythm looks like this.
- Plan a short cycle, typically one to two weeks, with a clear goal.
- Build and test it.
- Show working software to the people making decisions.
- Adjust the plan based on what you see.
Regular demos keep the project honest. They also prevent the most costly MVP failure: building for months in private, then discovering in the final week that the product misses the point.
How much does an MVP cost?
The range is wide because the options are. As planning figures for a small, senior team:
- A clickable prototype often costs a few thousand dollars.
- A working web MVP commonly falls between $8,000 and $25,000.
- A product delivered on web and mobile often costs $20,000 to $50,000.
The number depends mainly on how many user types and journeys the first release supports, how much design it needs and which integrations cannot be avoided. Our MVP cost guide breaks down these ranges and the factors behind them, and web application development cost covers the broader picture.
The most reliable way to keep costs down is to have less in the first release, not to negotiate rates.
Common MVP mistakes
- Building too much. Adding features "just in case" is the main reason MVPs stop being minimal.
- Not naming the question. Without a goal, you cannot tell whether the MVP succeeded.
- Ignoring quality. Minimal does not mean unreliable. Bugs in the core journey will mask whether the idea is good.
- Polishing before proving. Custom visuals and animation can wait.
- Skipping users. Talk to people before, during and after the build.
- Measuring the wrong things. Sign-ups flatter; repeat use and payment are more honest signals.
- Treating launch as the finish line. The MVP is the beginning of learning, not the end of work.
- Choosing technology for novelty. Use reliable, mainstream tools so you can change direction easily.
How to know if the MVP worked
Decide on success measures before launch, and keep them few. Examples:
- How many users complete the core journey?
- How many come back within a week or a month?
- How many pay, or say they would?
- What do users ask for most often?
- Where do they drop out?
Compare the results with what you expected. Three outcomes are possible: evidence to continue, evidence to change direction (often called a pivot), or evidence to stop. All three are valuable, and the last saves more money than any other.
What to do after the MVP
If the results are positive, you can plan the next stage with confidence.
- Fix what holds people back. Drop-off points and common complaints come first.
- Add the most requested features, using the "later" list.
- Strengthen the foundations. Security, performance and monitoring deserve more attention as usage grows.
- Consider a longer-term team. Products with a continuing roadmap often benefit from a dedicated group; see hire a dedicated software team and dedicated team vs freelancers vs in-house.
If you design the MVP with sensible structure and clean code, the next stage builds on it rather than replacing it.
Who benefits most from the MVP approach
The method suits anyone facing uncertainty: founders with a new idea, companies launching a new product line, and teams adding a major feature. Our page for startups and founders describes how this works for early-stage products, and product teams covers the in-house version.
A compact MVP checklist
Before you start building, confirm you can answer yes to each of these.
- I can state the assumption this MVP tests in one sentence.
- I know who the first users are and how I will reach them.
- The core journey is written down in a few steps.
- The "later" list exists and I have agreed to use it.
- I have chosen success measures and targets.
- The platform and technology choices are justified.
- The budget is sized to the smallest version that can test the assumption.
Final thoughts
The value of an MVP is not that it is cheap. It is that it makes learning cheap. By building the smallest thing that can prove or disprove your riskiest assumption, you spend early money on evidence rather than on guesses.
If you have an idea and want help deciding what the first version should be, talk to us. We will help you name the assumption, cut the scope and plan a build that teaches you the most for the least.