The key points
- An MVP exists to buy information as cheaply as possible.
- It is a working product, not a mock-up or a slide deck.
- It tests one assumption that would end the idea if wrong.
- Features that feel like progress but prove nothing are left out.
What does MVP mean in software development?
MVP stands for minimum viable product. In software development it means the smallest version of a product that real people can actually use, built to answer one question about whether the idea works. The phrase was popularised by the Lean Startup approach, where the aim is to learn as much as possible about customers with the least effort.
Each word does work. Minimum means you leave out everything that does not help answer the question. Viable means what remains has to function well enough that people can complete the one task it exists for. Product means it is real, working software on real infrastructure, not a mock-up. An MVP sits early in the software development life cycle, after the idea has been checked and before the full build.
What problem does an MVP solve?
Most new products fail because nobody wanted them, not because the code was poor. Building the whole thing first means finding that out at the most expensive moment. An MVP moves the discovery to the start: build only what is needed to test whether the core idea holds, put it in front of real users and watch what they do. Before even that, it pays to validate the idea before you build.
What belongs in an MVP and what does not?
Start from the assumption that would end the business if it were wrong, and build the smallest thing that tests it. Settings screens, admin panels, analytics dashboards and polished onboarding all feel like progress and prove nothing about demand. Leave them out until usage earns them. Most of deciding which features an MVP needs is deciding what waits.
What stays must work properly. A rough product that fails at the one thing it exists to do teaches you nothing, because you cannot tell whether people rejected the idea or the execution.
What do you receive at the end?
A working product on real infrastructure with real accounts, a technical roadmap for the next version, a plan for testing with users and a launch approach. In our MVP development service, the repository, hosting, domain and third-party accounts are registered to you from the start, and three months of support follow the launch, covering the development support a startup needs after launch.
How is an MVP different from a proof of concept?
A proof of concept checks whether something can be done technically, such as whether a service can read a certain kind of document. Nobody outside the team is meant to use it. An MVP checks whether anyone wants the result, so it has to be usable by real people for a real task. Many projects need a small proof of concept first if the technical risk is high, then an MVP once it works.
MVP compared with a prototype and a full product
| Aspect | Prototype | MVP | Full product |
|---|---|---|---|
| Purpose | Show how it could work | Test real demand and behavior | Serve a proven audience at scale |
| Working software | Usually not | Yes, on real infrastructure | Yes, with full feature set |
| Real users | Feedback on a concept | Used for real tasks | Large and ongoing |
| Scope | Key screens or flows | One core assumption | Everything the roadmap earns |
Test your MVP idea
- What single assumption would end this idea if it were wrong?
- How will you know within weeks whether it held?
- Who are the first ten real users, and can you reach them already?
- What are you prepared to leave out of version one?
Sources
Rules and guidance this answer relies on. Policies change, so check the current version before acting on it.