MVP development is the work of building the smallest version of a product that real users will adopt, and ideally pay for, so you learn whether the idea holds before you fund the full build. Done well, it is a sharp business experiment with a working product attached, not a cheap or unfinished app. This guide covers what an MVP is for, how it differs from a prototype, a proof of concept and an MLP, the scope rules, the step-by-step process, the timeline by phase, what drives the cost, life after launch, GDPR basics and a scope checklist.
Last updated: 19 October 2026.
What is an MVP for?
A minimum viable product (MVP) is the first release of a product that solves one real problem for one defined group of users well enough that they choose to use it. “Minimum” refers to scope, not quality. “Viable” means it works, it is safe to use, and someone gets enough value from it to come back.
The purpose of an MVP is learning that you can act on. You are testing a small number of risky assumptions: that the problem is real, that people will change their habits to solve it, and that someone will pay. Every feature that does not help test those assumptions is a cost with no return at this stage.
That is why the best measure of an MVP is not how much it does, but how clearly it answers the question it was built to answer. At Odduel, a creative and technology agency in Barcelona and São Paulo, we start every application development project for a new product with that question written down, before any screen is drawn.
In short: an MVP is a working product with the smallest scope that can prove or disprove your riskiest assumption. It must be good enough that real people use it without being asked twice. It is a step towards a business, not a demo. If it cannot teach you something you will act on, it is not yet an MVP.
MVP, prototype, proof of concept or MLP: what is the difference?
These four words are often used as if they meant the same thing. They do not, and mixing them up is one of the most common reasons first versions take too long or cost too much. Each answers a different question for a different audience.
| Proof of concept | Prototype | MVP | MLP (minimum lovable product) | |
|---|---|---|---|---|
| Question it answers | Can this be built? | Does this make sense to users? | Will people use it and pay? | Will people love it and tell others? |
| Who sees it | Your team, investors | Test users, stakeholders | Real users in the market | Real users in a crowded market |
| Does it work for real | Only the risky technical part | No, it looks like it works | Yes, end to end | Yes, end to end, with polish |
| Real data and accounts | Rarely | No | Yes | Yes |
| What it is made of | Code, often throwaway | Design files, clickable screens | Production code | Production code and finished brand |
| What comes next | A prototype or a decision to stop | An MVP | Iterations based on usage | Growth and scale |
A proof of concept removes technical doubt, for example whether an integration or an algorithm behaves as hoped. A prototype removes doubt about the experience: you can watch people try to complete a task on clickable screens before any code exists. The MVP is the first thing you put in front of the market.
The MLP is a useful idea when your market already has good alternatives. In that case “it works” is not enough to make anyone switch, and a share of the first budget belongs to the feel of the product: its brand, its words and the care in its details. Many good first versions sit between an MVP and an MLP: narrow in scope, but finished in everything they do include.
How do you decide what goes into an MVP?
Scope is where most first versions succeed or fail. A team that cannot say no to features ends up with a slow, expensive build that tests nothing clearly. These rules keep scope honest.
Scope rules that hold up
- One user, one problem, one main journey. Name the user in a sentence and the job they need done. Everything in the first release supports that journey from start to finish.
- Write the riskiest assumption first. If the biggest doubt is “will restaurants pay monthly for this”, the MVP must include a way to pay, even if the rest is plain.
- Manual behind the scenes is allowed. Tasks that would take weeks to automate can be done by hand for the first users. Automate once you know the task is needed.
- Cut features, not quality. A smaller product that works reliably teaches you more than a larger one that breaks. Security, accessibility and data handling are not optional extras.
- Buy what is not your difference. Payments, sign-in, email delivery and analytics are solved problems. Use proven services and spend your budget on the part only you offer.
- Every feature names its measure. If you cannot say what number or behaviour will show that a feature works, it waits for a later release.
A simple method is to list every feature anyone has suggested, then sort each into “the journey breaks without it”, “it helps but the journey works”, and “later”. Only the first group goes into the MVP. The second group becomes the first candidates for the next release, ordered by what users actually ask for.
What is the MVP development process, step by step?
The process below is the one we follow for new products. The order matters more than the names of the stages: each step reduces a risk before money is spent on the next.
- Frame the problem and what you need to prove. Write who the user is, what they do today instead, why that is painful, and what success would look like after launch. Agree on the one or two numbers that will tell you whether to continue.
- Talk to users before designing. Short interviews with people who match your target user reveal the words they use, the workarounds they rely on and the price they find reasonable. This is the cheapest research you will ever do.
- Map the main journey. Draw the path from first visit to the moment the user gets value, step by step. This map becomes the scope: anything not on it is outside the MVP.
- Prototype and test. Turn the journey into clickable screens and watch five or so people try to complete it. Fix what confuses them. Changes here cost hours; the same changes in code cost weeks.
- Choose the platform and the stack. Decide between a web app, a native app or a cross-platform app based on where your users are and what the product needs from the device. Our guide to startup digital foundations covers the wider choices a new company faces.
- Build in short cycles. Work in one- or two-week cycles, each ending with something working that you can try. This is where an approach that mixes a fixed discovery with agile build cycles pays off; we compare the options in agile vs waterfall.
- Test with real users before launch. A closed group of early users finds the bugs and the confusing moments that the team no longer sees. Check accessibility, performance on ordinary phones and the sign-up and payment steps above all.
- Launch to a defined audience. Launch to the group you can reach and learn from, not to everyone. A focused landing page that explains the product and collects sign-ups often does more than a broad campaign; see our guide on landing page design cost.
- Measure, learn and decide. Compare usage with the numbers you agreed in step one. Then decide: continue and improve, change direction, or stop. All three are valid results of a good MVP.
How long does MVP development take?
The honest answer depends on the scope, the platform and how quickly decisions are made on the client side. What can be said with confidence is how the time divides between phases, and which phases tend to stretch.
| Phase | Typical share of the time | What tends to stretch it |
|---|---|---|
| Framing and user research | A small share at the start | Unclear ownership of the decision |
| Journey mapping and prototype | A small to moderate share | Too many stakeholders reviewing screens |
| Build cycles | The largest share | Scope added during the build, integrations with third parties |
| Testing with early users | A moderate share | Payment and sign-in edge cases, app store review |
| Launch and first measurement | A short phase, then ongoing | Waiting for enough usage to read the numbers |
Two points are worth knowing. First, the build is the largest phase, but the phases before it decide how long it takes: a tested prototype and a firm scope shorten the build more than any amount of extra effort during it. Second, native apps add a step that websites do not have, because the app stores review every release. Apple publishes its rules in the App Store Review Guidelines, and a first submission can be sent back for changes, so plan for it.
AI now carries much of the repetitive production in our projects: design-system components, front-end code, first drafts of copy, test cases and first-pass translations. That shortens the build and lowers its cost. The strategy, the decisions on scope, the design of the experience and the final review of every release remain human work, and that is where the time of a first version is best spent.
What drives the cost of an MVP?
Without a scope there is no honest price, so instead of figures, here are the lines that make up a quote and what makes each one larger or smaller. A fixed quote follows a short brief, once the main journey is clear.
The cost lines
- Discovery and research. A fraction of the total, and the line that most reduces the rest. Skipping it usually moves the cost into the build, where it is larger.
- Experience and interface design. Grows with the number of distinct screens and states, not with how polished they look. An MLP spends more here.
- Build. The largest share. It grows with the number of user roles, the amount of business logic and every integration with another system.
- Integrations. Payments, maps, calendars, accounting tools or an existing database. Each one needs its own work and testing, and some services charge fees of their own.
- Testing and quality. Grows with the number of devices and browsers you must support and with how sensitive the data is.
- Infrastructure and services. Hosting, email delivery, analytics and monitoring. Small at first; grows with usage.
- Launch and store work. Store listings, screenshots, a landing page and the first measurement set-up.
What makes an MVP more expensive
The biggest drivers are, in order of how often we see them: several user roles from day one (for example customers, staff and administrators), native apps on two platforms instead of one web app, custom work for something a proven service already does, and scope that changes during the build. Even a new class of device, such as a foldable phone, adds layouts and testing to an app’s scope.
How to read a quote
A good quote lists the journey and the features it covers, what is excluded, the assumptions behind it, the cost lines above, and how changes are handled. Be careful with a single number and no scope: it either hides a large margin or leaves the hard parts for later. Ask what happens in the first months after launch, because that is where the budget is often forgotten.
What happens after the MVP launches?
Launch is the start of the useful part. For the first weeks, the team watches how people actually use the product: where they drop off, which features they ignore, what they ask for in support messages. That evidence replaces opinion when you decide what to build next.
Keep a short list of what you are measuring, such as how many sign-ups complete the main journey, how many come back after a week, and how many pay. Review it at a fixed rhythm, then plan the next cycle around the biggest problem the numbers show. Fix bugs and confusion before adding features.
Plan for the work that keeps a product healthy: security updates, operating system changes on phones, new versions of the services you rely on, and backups. A product that is not maintained loses the trust of its first users quickly, and those first users are the hardest to win back.
What does GDPR mean for an MVP with user data?
As soon as people create accounts, an MVP holds personal data, and the General Data Protection Regulation, which applies since 25 May 2018, applies to it like any other product used by people in the EU. Being small or early does not change that. The good news is that the basics are easier to build in at the start than to add later.
- Collect only what the journey needs. If you do not need a date of birth or a phone number to deliver the service, do not ask for it. This is the principle of data minimisation.
- Know your legal basis. For most account data it is the contract with the user; for marketing emails it is usually consent, given freely and recorded.
- Write a plain privacy notice. Say what you collect, why, how long you keep it, who processes it for you and how people can exercise their rights.
- Sign data processing agreements. Hosting, email, analytics and payment services that handle personal data on your behalf are processors; you need an agreement with each.
- Secure by default. Encrypt data in transit, store passwords properly, limit who on your side can see user data, and keep logs of access.
- Make rights practical. Users must be able to see, correct, export and delete their data. A simple way to request this, handled promptly, is enough for a first version.
- Ask for consent before trackers. Analytics and advertising cookies that are not strictly necessary load only after the user agrees.
This is general information, not legal advice. For anything sensitive, such as health or financial data, or data about children, have a lawyer review the product before launch.
MVP scope checklist
Use this list before any build starts. If an answer is missing, the scope is not ready.
- The target user is named in one sentence.
- The problem and the current workaround are written down.
- The riskiest assumption is named, and the MVP tests it directly.
- The main journey is mapped from first visit to the moment of value.
- Every feature is marked “journey breaks without it”, “helps” or “later”.
- The prototype has been tested with real people and fixed.
- The platform choice (web, native, cross-platform) has a reason.
- Payments, sign-in and email use proven services.
- Each feature in scope names the measure that shows it works.
- Personal data collected is the minimum the journey needs, with a privacy notice and processor agreements in place.
- Accessibility and performance on ordinary phones are part of testing.
- The two or three launch numbers and the review date are agreed.
- Someone on the client side owns decisions every week.
- There is a budget and a plan for the months after launch.
Questions people ask
What is the difference between an MVP and a prototype?
A prototype looks like a product but does not work for real: it is a set of clickable screens used to test whether people understand the experience. An MVP is a working product with real accounts and data, released to real users in the market. You usually build a prototype first, test it, then build the MVP.
How do you build an MVP without overspending?
Name one user, one problem and one main journey, and keep everything else out of the first release. Test a prototype before writing code, use proven services for payments and sign-in, and do some tasks by hand at first. Most overspending comes from scope added during the build, so agree how changes are handled before starting.
Should an MVP be a web app or a native app?
A web app is usually the faster and simpler first step, because it runs on every device from one build and needs no app store review. A native app makes sense when the product depends on the phone itself, such as offline use, the camera, background location or notifications, or when users expect to find it in a store.
Can a no-code tool be used for MVP development?
Yes, for some products. No-code tools can be a quick way to test demand for simple journeys such as bookings, directories or forms. They become limiting when the product needs custom logic, strict data handling, good performance or a distinct brand experience. Plan on rebuilding once the idea is proven, and check where the tool stores personal data.
When is an MVP finished?
An MVP is finished when it answers the question it was built for. That means enough real people have used it, over enough time, for the numbers you agreed at the start to point clearly one way: continue and improve, change direction, or stop. From then on you are no longer building an MVP but developing a product.
If you have an idea and want to turn it into a first version people use and pay for, start with a short brief: who the user is, the problem, and what you need to learn. We will help you shape the scope, test it and build it. See how we work on application development, or tell us about your product.
Further reading: Native vs cross-platform apps: Flutter, React Native or native, SaaS development cost in 2027: a breakdown by stage, App development: from idea to the store, How long does it take to build an app? A realistic timeline, Agentic AI vs generative AI: what each can do for a company.
