What a software MVP is, and how to launch your first one without overbuilding

A minimum viable product is the first version of a product with just enough for a group of real users to use it to solve their problem. It is “minimum” because it leaves out everything that is not essential, and “viable” because what it does include genuinely works: it can be used without explanations, and it does not break.

Its purpose is not to save money: it is to learn. With an MVP in users' hands you find out what they use, what they ignore and what they would pay for, before investing in everything else.

In sports, MVP means “most valuable player”. In software and in business, it always means minimum viable product.

The most common mistake is calling a pretty prototype nobody can use an MVP, or a half-built product where every feature is started and none is finished. An MVP does few things, but it does them completely.

Think of one user's path, from the first screen to having their problem solved. The MVP is that path and nothing more:

1. Getting in: sign-up or access, as short as possible. Sometimes an account is not even needed.
2. The core task: the one or two things someone would use the product for. Complete, with their normal cases handled.
3. The result: what the user walks away with (a document, a published menu, an order sent), visible and shareable.
4. The minimum for you to run it: see users, fix a record, know what is going on.
5. Measurement: knowing how many arrive, how many finish the task and how many come back.

Everything else (elaborate reports, integrations, fine-grained roles, customization, a mobile app) can wait until real use says it is needed.

Minimum does not mean improvised. Some things are cheap to decide at the start and expensive to change later:

• How you will charge. Per user, per seat, per use or per plan: it changes how the data is modelled. MenuFacil, for example, charges per seat, and each seat activates a restaurant; the model has to survive free trials, discounts and two currencies.
• Who can see what. Even if the MVP has a single kind of user, one customer's data must never mix with another's.
• Where the important decisions are made. In Brosino, every outcome and every balance is decided on the server; the browser never decides anything. It is the difference between a product that holds up with real users and one that can be cheated.
• Who owns the code and the accounts. If a provider builds your MVP, the code, the database and the accounts should be in your name from day one.

• Write the sentence “a [user] uses this to [result]”. Anything that does not serve that sentence leaves the first version.
• Swap screens for manual work while you can: approve by hand, send an email yourself, onboard customers one by one.
• Remove steps at the door. Every sign-up field is people who never reach the core task; in Brosino, for example, people join as guests, without creating an account.
• Leave out the nice-to-haves. If nobody asks for it once the product is in use, it was not needed.

An MVP is never finished: it becomes the foundation of the product. With real users, each next stage is decided with data instead of assumptions: what is used most gets better, what is asked for gets added and what nobody touches gets removed.

That is why it matters that the MVP is well built inside even if it does little outside. If the foundation holds, each stage is added on top; if not, the next step is a rewrite.