The short answer
A software MVP, short for minimum viable product, is the smallest version of a system that solves a real problem, is used in real work and shows whether the idea works. It is not a prototype or a half-baked version: it does little, but it is built for real use.
The goal of an MVP is to learn with the least possible effort before investing in the whole system. You pick the main pain, build only what is needed to solve it, put it into use and measure. If the result shows up, the system grows from there. If it does not, you found out early, while changing course is still cheap.
What an MVP is not: prototype, demo and half-baked version
The term has become a synonym for anything small, and that muddles the decision. A clickable prototype is for testing the flow and interface before writing code, but nobody works in it: the data is fake and nothing is saved. A demo is for persuading. And a half-baked version, with everything half done, teaches nothing, because nobody can use it enough to say whether it solved the problem.
An MVP sits between the prototype and the complete product. It does few things, but does them right, with security, real data and the care of someone who will keep building on top of it. The table sums up the difference.
| Aspect | Prototype | MVP | Complete product |
|---|---|---|---|
| What it is for | testing flow and interface before code | proving the system solves the main pain | serving the entire operation |
| Who uses it | users invited to a guided test | a real group of users, in their daily work | every planned user profile |
| Data | fictional, nothing is saved | production data, with security and compliance with Brazil's data protection law (LGPD) | production data, with every integration |
| What you learn | whether people understand the screens | whether real use produces the expected result | where to evolve and what to adjust |
| Is the code kept? | usually not, it is disposable | yes, it is the foundation for what comes next | yes, and it keeps evolving |
How to choose what goes into the MVP
The temptation is to include everything that seems important. The right criterion is different: what has to exist for the main pain to be solved completely, from start to finish, for at least one group of users. A few questions help you cut:
- What pain justifies the system? Write it in one sentence. Anything that does not help solve it is a candidate to wait.
- Who is the first group of users? One department, one unit or one type of service. Starting with a well defined group makes the result easier to measure.
- What is the complete path of the task? The MVP has to carry the task from start to finish. Half a flow working and the rest in a spreadsheet proves nothing.
- What can stay manual for now? A report put together by hand or a record entered by the team can wait for the second version without hurting the test.
- Which integration is essential? Integrate only what the task cannot do without. The rest come in the following sprints, with more information.
This cut is made in the initial study, together with the people who run the routine, and becomes a prioritized backlog. The guide on how to define the scope of a software project details that work, and the one on product discovery shows how to validate hypotheses before building.
How to measure whether the MVP validated
An MVP only teaches if the question was asked beforehand. That is why the success criterion is agreed together with the scope, not after the system is live. Without it, any result becomes a reason to keep going.
The most useful signals are usually easy to observe in the system itself and in the team's routine:
- Spontaneous use. Do people use the system without being reminded, or do they go back to the old spreadsheet at the first difficulty?
- Task time. Did the task that motivated the system get faster, with fewer steps or less back and forth?
- Errors and rework. Are there fewer discrepancies, fewer re-entries and fewer after the fact corrections?
- Data for decisions. Can management now see in the system the number that used to depend on someone building a spreadsheet?
- User requests. Are incoming requests about expanding, a sign the basics work, or about fixing the basics?
With these signals in hand, the decision has three honest outcomes: continue and expand, adjust what did not work, or stop before investing more. All three are valid results of an MVP. The only bad outcome is not deciding.
Does an MVP make sense for internal systems and public agencies?
It does, sometimes even more than for a product sold on the market. In an internal system the users are in house, which makes it easier to observe use and listen to the people who run the operation. Starting with one department or one routine reduces the risk of replacing everything at once and gives the team time to adapt while the rest is built.
In the public sector the logic is the same, with its own precautions. Procurement follows public bidding rules and the object of the contract must be described, so the MVP appears as the first stage of a scope planned in phases, not as improvisation. Accessibility requirements, the LGPD and the logging of every action come in from the first version, because a system that serves citizens cannot treat them as a future improvement. The guide on hiring software for a public agency goes deeper into this path.
In healthcare, for example, our patient management system for urgent care is built in sprints with demos, each part of the flow validated before the next.
Common mistakes when building an MVP
- Calling the whole system with a tight deadline an MVP. If nothing was cut, it is not an MVP. It is the complete project with less time, and the result is usually worse on both counts.
- Cutting quality instead of cutting scope. An MVP is small in what it does, not in the care it gets. Security, tests and reviewed code still apply, because the system will grow on top of that foundation.
- Not defining success beforehand. Without an agreed criterion, the MVP becomes an eternal first version that nobody knows whether it worked.
- Testing only with management. The people who decide are not the people who operate. If the people in the routine do not use the MVP, the test did not measure what matters.
- Forgetting what comes next. The MVP has to fit into a plan. Without a backlog for the next stages, the learning gets lost.
How we build an MVP in practice
Our custom software development starts with a short study that defines the scope, the priorities and what goes into the first version. From there we follow the cycle described in how we work: short sprints, each one ending with working software for you to test, comment on and approve.
The MVP is the first delivery that goes into real use, and what it shows decides the order of the following sprints. If you want to understand how long each stage usually takes, the guide on how long it takes to develop a custom system explains what weighs on the timeline.