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 is built to create evidence about the riskiest assumption, at production quality, so validated work carries forward.
Start with the assumption
The useful question for version one is “what must be true for this product to be worth building?” Design the MVP to answer that question as cheaply and clearly as possible, and let the feature list follow from it.
A smaller product can still be production quality
Scope and engineering quality are different variables. A narrow product can still have sensible authentication, data handling, logging, deployment and code structure. Keeping those foundations is what makes the next release fast.
What to leave for later
- Features that leave the core product decision unchanged.
- Generalisation for hypothetical future users.
- Integrations you can simulate while the product thesis is still uncertain.
- Complex role models, until the first real workflow needs them.
- Architecture for scale the product has yet to earn.
When is the MVP successful?
An MVP succeeds when the release produces enough evidence to make the next decision: continue, change the product, narrow the user, improve a critical workflow or stop.
See how Digitalis approaches MVP and product software development.