Software development
What makes a good software MVP?
The short answer
A good MVP is the smallest coherent product that can test the product thesis. It should create evidence about the riskiest assumption, not reproduce the final product at lower fidelity.
Start with the assumption, not the feature list
The useful question is not “which features can we fit into version one?” It is “what must be true for this product to be worth building?” The MVP should be designed to answer that question as cheaply and clearly as possible.
A smaller product can still be production quality
Scope and engineering quality are different variables. The product can be narrow while still having sensible authentication, data handling, logging, deployment and code structure. Cutting those indiscriminately often creates rework rather than speed.
What should be excluded?
- Features that do not change the core product decision.
- Generalisation for hypothetical future users.
- Integrations that can be simulated while the product thesis is still uncertain.
- Complex role models before the first real workflow requires them.
- Architecture built for scale the product has not earned.
When is the MVP successful?
Success is not “the build shipped”. Success is that the release produced enough evidence to make the next decision: continue, change the product, narrow the user, improve a critical workflow or stop.