Committing a large budget on the strength of written requirements is one of the most reliable ways to waste it. Build a working version first: the economics of doing so have never been better.
There is a conversation we keep having about new products and systems. It goes something like: “We don’t need an MVP, we know what we want from our existing systems.” There is a variation: “We need an MVP, and the budget is well beyond £100k.” Behind both sits real pressure: commercial urgency, operational frustration, and quite often a well-connected software sales team helpfully adding to the push to get going.
Where the requirements come from
In this situation the requirements are usually documented from the experience of the product manager or the chief executive, often by pointing at existing applications: the new solution will be a single, simpler version of the several systems in use today. Those documents then drive the tender, or set the size of the internal team.
Written requirements alone are a significant risk
Basing a large build on requirements documents has three problems, and we see them consistently.
First, the documents are rarely read properly. Their whole purpose is shared understanding, which makes them long and dense, and busy people speed-read them. The full story never transfers.
Second, you do not know what you want until you see it. A new solution is almost never a replica of the old ones: the flows are different, and when they are built and tried, they change the requirements. This is Clarkson’s law, and it has its own article.
Third, requirements lose the interconnectedness of ideas. Jeff Bezos banned PowerPoint at Amazon for exactly this reason:
PowerPoint-style presentations somehow give permission to gloss over ideas, flatten out any sense of relative importance, and ignore the interconnectedness of ideas.
Jeff Bezos
In digital projects, the user stories are the bullet points. They are not wrong; they are just not the full story. They cannot say how the features fit together, or what becomes possible when several of them do.
The MVP is your insurance policy
The answer is to build a working version of the intended solution that captures the functional heart of the bigger build. It costs a fraction of the full implementation, and it pays for itself several ways over.
- It prices the big build far more accurately than documents alone.
- It absorbs the cheap iterations, so the expensive phase needs fewer of them.
- It gives stakeholders something real to react to early, which is where buy-in comes from.
- It defers the larger investment until the thinking has been tested.
- It lets the data model, user journeys and core architecture be proven in use, and that learning passes straight into the scale build.
There is one honest exception: where most of the big budget is going on non-functional work such as performance, security and capacity, an MVP earns less of its keep.
The cheapest outcome an MVP can buy is a no
An entrepreneur with a corporate leadership background came to us with a proven methodology and a plan to turn it into a product. Instead of commissioning the big build, we defined the proposition, built a working proof of concept, and tested it with a multinational prospect. The evidence said stop. That decision cost a fraction of a scale budget, and it came with the development cost, required investment and risk all quantified, and the know-how retained for another day. A cheap, well-evidenced no is one of the most valuable things a working version can deliver.
The economics have moved. The argument has not.
When we first wrote this piece, our advice was that a typical MVP should come in under £50k. AI-assisted delivery has moved the number without touching the logic: our own first working solutions now start at £8,500 and arrive in four weeks. The cheaper the working version gets, the less defensible it becomes to spend six figures on faith.
One caution, which has its own article: an AI-era prototype looks finished long before it is. Treat it as the MVP it is, and make the scale investment when the market has voted.
The point
Before signing off a large build, ask three questions. Are there features and flows you want that exist nowhere today? How much of the budget would be spent rediscovering the requirements mid-project? And would your investors breathe easier if they could see a working version first? If any of those sting, build the MVP.
