Fourteen months of development, and on delivery day it turns out the department now works differently from the way the original plan described. We still run into that scenario in conversations with organizations, and it is exactly the problem an MVP is meant to prevent.
Search for "what is an MVP" and you'll find two worlds. In sports, MVP stands for most valuable player, the best player of a game or a season. The meaning that matters here is the other one: minimum viable product, a term from software development that describes how to start a new product sensibly.
An MVP (minimum viable product) is the smallest working version of a product that lets you test with real users whether the idea delivers value. It contains only the features needed to solve one core problem, and it produces measurable feedback before you invest further. The goal is to learn with as little building as possible.
MVP meaning: learn first, then build
The term comes from the startup world. Frank Robinson used it around 2001, and Eric Ries made it famous with his book The Lean Startup. The core of his argument: every product is an assumption about what users want, and the cheapest way to test that assumption is a small version that you put in front of users as quickly as possible.
For organizations that commission software, that is a shift in thinking. Instead of a full set of requirements built in one go, you pick the one process that hurts the most, build a working solution for that process, and measure what happens. What you learn decides the next step. What you don't need to learn, you don't need to build.
Take Joris, head of the operations office at an installation company with 120 field technicians. His planners work in three spreadsheets and spend every day on the phone passing on changes. The wish list for a new scheduling tool runs to 40 items, from time tracking to a link with the accounting package. The MVP limits itself to one thing: the weekly schedule for one region, visible on each technician's phone, with a push notification for every change. After six weeks of use, Joris knows whether the phone calls have dropped and which of the other 39 wishes still matter.
That is the value of an MVP in one sentence: you prove with the smallest version that the direction is right, and you then spend your budget on the things you know work. Our page on custom software development shows how such a first version grows into a full application.
MVP vs prototype, proof of concept, and pilot: the differences
The terms get used interchangeably, yet each one answers a different question. A prototype shows what something looks like, a proof of concept shows that something is technically possible, an MVP shows that something has value, and a pilot tests whether a finished product works for a wider group.
| Form | What it tests | Working software | Users | What happens next |
|---|---|---|---|---|
| Prototype | Whether users understand the design | No, clickable screens or sketches | Test panel, usually internal | Thrown away |
| Proof of concept | Whether something is technically possible, such as a link with an old ERP | Partly, often throwaway code | Developers | Thrown away or rebuilt |
| MVP | Whether the core problem is solved and people use it | Yes, production-ready and small | A defined group of real users | Grows into the full product |
| Pilot | Whether the full product works for a wider group | Yes, complete | A department, site, or customer group | Wider rollout |
The most important difference sits in the last column. You throw a prototype and a proof of concept away as soon as you have the answer. An MVP is built on a foundation that can grow: the same architecture, the same security, and the same tests as the final application, only with far fewer features. Treat an MVP as throwaway code and you'll pay for the build twice.
How to build an MVP: setting the scope
Setting the scope of an MVP is the hardest part, because everyone at the table has a list of their own. Three boundaries help keep those lists small.
One core process
Pick the process that currently absorbs the most time, errors, or frustration. Everything that touches that process belongs in the MVP. Everything next to it goes on the list for later. For Joris that was the weekly schedule. Time tracking went on the list for later, even though the finance department asked for it loudest.
One user group
An MVP that has to work for planners, technicians, customers, and the board at the same time is no longer an MVP. Choose the group that runs the process every day and build for them. Other users get their turn in a later version, with the feedback from the first group as the starting point.
One measurable goal
Agree up front what success looks like and how you'll measure it. Fewer phone calls per day, a shorter turnaround per request, fewer errors per week: the number you pick matters less than recording it before the build and comparing it after six to eight weeks of use. Without a measurement plan, the evaluation turns into a battle of opinions.
Example: an internal portal for one department
Fatima is IT manager at a healthcare organization with 900 employees. Leave requests, shift swaps, and expense claims run through email and paper forms, and the wish list for an employee portal doesn't fit on a single page. She opts for an MVP: shift swaps only, for the home care department with 60 employees only, with the goal of getting a swap approved within a day instead of within a week.
After two months the portal clearly works, and employees say what they value most is the view of their own schedule. That view wasn't on anyone's list. The next version therefore gets a schedule overview first, then leave requests, and only then expense claims. If you're unsure which process is the right candidate for a first version, we'll look at it with you in an independent consulting session, even when the answer turns out to be that you're better off sticking with standard software.
From MVP to mature software
An MVP is a starting point. Its value lies in what you do with it after the first users have worked with it. In practice, this is where things most often go wrong, for three recognizable reasons.
Three common mistakes
- Too many features. Every extra feature makes the build longer and the feedback vaguer. If the MVP still has no users after three months, the scope was too big.
- No measurement plan. Without an agreed goal, nobody knows afterwards whether the MVP succeeded, and the loudest voice in the room decides what happens next.
- An MVP that never grows up. Sometimes the first version stays in use for years without maintenance, security updates, or further development. That version turns into a liability for the organization.
How an MVP grows
The transition to mature software takes the same discipline as the MVP itself. Measure what users do, pick the features with the most impact in every cycle of two to three weeks, and deliver them working. At the same time, arrange the things that often wait during a first version: maintenance, monitoring, backups, access management, and documentation.
At Isatis, we therefore build an MVP on the same technical foundation as the later application from day one. Our team of 30+ engineers in Nijmegen and Sarajevo works to ISO 9001 and ISO 27001, including in the first version, so security and quality never need a catch-up round later. And because the people who build the MVP are the same people who keep the software running afterwards, no knowledge gets lost between version one and version ten. You can read what such a journey from first version to production looks like on our custom software development page.
If you bring in an external partner for your MVP, pay close attention to who maintains the code after the first version and whether that team stays. Our article on how to choose a software company lists the questions to ask.
Frequently asked questions
What does MVP stand for?
MVP stands for minimum viable product: the smallest working version of a product that offers enough value to test with real users whether the idea holds up. In sports, MVP means most valuable player, the best player of a game or a season. For a detailed background on the term, see the Wikipedia article on minimum viable product.
What is the difference between an MVP and a prototype?
A prototype shows what something looks like and usually consists of clickable screens or sketches that you throw away after the test. An MVP is working software that a defined group of users relies on in practice and that then grows into the full product.
How long does it take to build an MVP?
That depends on the core process and the number of integrations. A well-scoped MVP often reaches its first users within a few weeks to a couple of months. If the build takes longer than three months without anyone using it, the scope is usually too big.
What does an MVP cost?
The cost depends on the size of the core process, the number of integrations with existing systems, and the quality requirements, such as security in healthcare. Naming a figure without knowing the assignment would be a guess. After an initial conversation we give a concrete estimate with clear assumptions, and in what custom software costs we explain which factors set the price.
In summary
An MVP is the smallest working version of a product that proves the direction is right before you invest further. The key points:
- Choose one core process, one user group, and one measurable goal.
- An MVP is working software on a foundation that can grow. A prototype and a proof of concept get thrown away.
- Without a measurement plan, the evaluation turns into a battle of opinions.
- The value lies in what comes next: measuring, prioritizing, and building on in short cycles, with the same team that built the first version.
The next step is a conversation about the process that hurts most in your organization. We have been building software for healthcare, education, manufacturing, government, and energy for more than 30 years, with 100+ projects to show for it. Book a no-obligation conversation and together we'll define the smallest version that tests your assumption.
