Scoping an MVP without building the wrong thing
An MVP is not a budget version of the final product. It is the smallest thing that answers a specific question about your business, and everything else is deliberately deferred.
Name the question first
Write the sentence: this release exists to find out whether ______. If you cannot fill the blank with something falsifiable, such as whether customers will pay a deposit online, the scope will expand until it includes everything.
Once the question is clear, features are easy to rank: anything that does not change the answer is out of the first release.
Manual behind the curtain is allowed
Many MVPs are half software and half human process. If a report can be produced by hand for twenty customers, build the customer-facing part and produce the report yourself until volume justifies automating it.
This is not a shortcut; it is information gathering. You learn the real rules of the report before you encode them.
Design the exit deliberately
Decide in advance what happens to the MVP code. If it will be replaced, keep it small and do not over-invest in polish. If it will grow into the product, build the data model and access rules properly even if the interface is thin.
Common questions
- How long should an MVP take to build?
- Six to twelve weeks is a common range for a focused first release with one core flow. Longer timelines usually indicate the scope contains more than one product.
- Should an MVP be launched to real customers?
- Yes, with a defined group. A release that only internal staff see answers questions about your process, not about customer behaviour.
Next step
If this question is live in your business right now, describe the situation and you will get a written view on the options, including whether you should build at all.
Discuss your projectRelated notes
All insightsCustom software or off-the-shelf: how to decide
A practical framework for choosing between configuring an existing product and commissioning custom software, based on where your process actually differs.
ReadStrategyHow to write a technical brief that gets accurate quotes
The brief structure that separates a project that can be estimated from one that cannot, with the eight sections worth writing before you talk to any developer.
ReadStrategyRebuild or repair: an honest test for an ageing website
How to tell whether your existing website needs a migration or a targeted fix, using five checks that take an afternoon rather than a month.
Read