MVP development: scope, cost, and timeline
How to define a first version that proves something, without spending a year building it.
Short answer
An MVP should test your single riskiest assumption with the least software possible. Scope it to one core flow for one type of user, plan in weeks rather than months, and treat anything that does not test the assumption (admin panels, settings, extra roles) as out of scope until the answer is in.
Start from the riskiest assumption
Every product rests on an assumption that, if false, makes the rest pointless. Sometimes it is demand, sometimes willingness to pay, sometimes whether the thing is technically possible at acceptable cost. Name it explicitly, then build only what is needed to test it.
What actually drives cost
- Number of distinct user roles, each one multiplies flows and permissions.
- Integrations with third-party systems you do not control.
- Real-time behaviour, payments, and anything regulated.
- Polish level, a demo and a production system are different products.
A realistic shape
A focused MVP with one core flow, one user role, and no exotic integrations is typically a matter of weeks, not quarters. When a first version is quoted in many months, it is usually because the scope is not an MVP. It is version one of the full product wearing an MVP label.
Mistakes that stretch a first version
- Building an admin panel before you have users to administer.
- Supporting several user types before proving one.
- Optimising for scale you do not have yet.
- Treating design polish as a prerequisite for learning.
- Refusing to do anything manually behind the scenes.
Common questions
How long should an MVP take to build?
- A properly scoped MVP (one core flow, one user type) is usually weeks rather than months. If the estimate runs to many months, the scope is almost certainly larger than an MVP.
Should an MVP be throwaway code?
- No, but it should be small. Keep the code clean enough to extend, and keep the surface area small enough that throwing part of it away is cheap if the answer surprises you.
What should an MVP deliberately leave out?
- Anything that does not test the core assumption: admin tooling, settings screens, secondary roles, extensive onboarding, and scale optimisation. Manual processes behind the scenes are usually cheaper than software at this stage.