An MVP is the smallest working release that answers an important question.
A minimum viable product is a working piece of software, used by real people, that is deliberately limited to the features needed to test a specific question. The question is usually about demand or behavior: will customers pay for this, will staff adopt this process, will partners submit information this way. The MVP exists to answer that question with evidence.
Minimum refers to scope, not quality. An MVP should be reliable, secure, and pleasant to use for the narrow task it covers, because a buggy release teaches you about the bugs rather than about the idea. Viable means someone can complete the task from start to finish without a workaround or a phone call to the team that built it.
An MVP is different from a prototype, which shows how something might look or work but is not used for real transactions. It is also different from a first release of internal software, where the need is already known and the goal is to put a proven process into a better tool. The distinction changes what you build first.
Build an MVP when the biggest risk is whether people will use it.
The MVP approach fits new products and services: a customer portal you are not sure customers want, a software product you plan to sell, a marketplace that depends on two sides showing up, or a new service line delivered through an application. In each case, building the full vision before testing demand risks spending heavily on the wrong thing.
It also fits changes to how a business reaches its customers. If you are considering online ordering, self-service scheduling, or a mobile app for clients, a narrow first version can show whether customers adopt it and what they ask for next. That evidence is more useful than any survey conducted beforehand, because it reflects what people actually do.
The approach fits less well when the need is already proven. If your dispatchers are running jobs from a whiteboard and a spreadsheet, there is no need to test whether they want a dispatch system. What they need is a well-scoped first release that handles the real work, including its exceptions, so the team can stop relying on the old method.
Choose one complete task and decide what evidence counts.
Write down the single question the MVP must answer, then identify the smallest task that answers it. For a customer portal, that might be checking order status and downloading invoices. For a new software product, it might be the one workflow a paying customer would miss most if it were taken away tomorrow.
Cut everything that does not serve that task. Administrative screens can often be handled manually behind the scenes. Reports can be simple exports. Some integrations can wait if a person can bridge the gap for a while. Each deferred feature goes on a written list so the decision stays visible and can be reversed when evidence supports it.
Decide in advance what would count as success and what would count as a signal to change direction. Usage, repeat visits, completed transactions, support requests, and direct feedback are all useful. Build in the basic analytics or logging needed to see them, while keeping personal data collection to what the task actually requires.
Avoid the common ways an MVP goes wrong.
The most common mistake is letting the MVP grow. Each stakeholder adds one essential feature, and the release becomes a full product built without the evidence it was meant to gather. Protect the scope by tying every feature to the question the MVP is testing, and move anything that does not fit onto the later list.
The opposite mistake is cutting so deeply that the product cannot be judged fairly. If users cannot finish the task, their lack of interest says nothing about the idea. Security, data handling, and accessibility also belong in the first version, because problems in these areas are expensive to fix after real users arrive and start relying on it.
A third mistake is building the MVP on a foundation that cannot grow. Minimum scope does not require throwaway code. Sensible choices about hosting, data structure, and authentication let a successful MVP become the base of the full product instead of a rewrite that arrives just as demand appears and the business can least afford a pause.
Plan what happens after the MVP before you launch it.
An MVP produces a decision. The evidence may show that the idea works and should be extended, that it works for a different audience than expected, or that it should stop. Agree beforehand who will review the results and how the next phase will be scoped, so the learning turns into action instead of debate.
If the idea works, the next priorities usually come from what users asked for and where they struggled. Scope each phase in writing when its turn comes rather than committing to a long feature list upfront. This keeps investment tied to evidence and avoids building features that the first release showed nobody needed.
Baybloom approaches an MVP as the first phase of a product rather than a disposable experiment, with the scope and price set in writing before work starts. Whichever partner you choose, ask how they would keep the first release narrow and how they would carry it forward if it succeeds.
Put it into practice
Talk through the project you are considering.
Bring the workflow, the systems around it, and the questions you need to resolve. We can help define a useful next step.
Discuss your project