Commissioning an MVP: why a prototype is often a better start than a requirements specification

One sentence comes up early in many project conversations: "Let's write everything down first, then you can send an offer." It sounds reasonable. After all, anyone building a house wants to see plans before the excavator arrives. With software the comparison only goes so far, because it is hard to add a floor to a house after you have moved in, while an input form is much easier to change.

Suppose a company with twenty employees wants to replace its order management. The managing director and two team leaders spend six weeks writing a requirements specification. It runs to eighty pages, with role models, status diagrams and a list of more than a hundred must-have criteria. Everyone is proud of it, and nobody has spoken in the meantime to the colleagues at the counter and on the phone who will actually work with it.

A document can describe what you have in mind, but it cannot show whether the idea holds up in everyday work. This difference becomes expensive later, and it has recurring causes.

There are recurring mechanisms behind this. The first: people describe the intended state of their work, not the actual one. The note on the monitor, the private Excel list, the call to the colleague who "always knows" do not appear in the specification because they count as workarounds. Yet it is often exactly these workarounds that keep the business running.

The second mechanism is the pressure to be complete. A document of this size is supposed to settle everything, so every special case anyone can think of is included. Rare cases get the same weight as the everyday normal case. In the end it is unclear what really matters, and a quote has to treat everything alike. The third mechanism is less obvious: anyone describing a field does not see how it feels to fill it in twenty times a day.

Then there is language. A sentence like "The system shall manage orders flexibly" can be implemented in ten ways, and all ten are formally correct. The dispute arises only at acceptance, when each side considers its own reading the right one. The document then has legal effect, but no power to clarify.

Typical patterns of failure that result from this look like this:

Before any decision on approach and contract, it is worth taking a sober inventory of what is uncertain about the project. Technical feasibility rarely is, for most business applications. Forms, lists, roles, notifications and interfaces to common systems are solved problems. What is almost always uncertain are assumptions about people and processes: will the team use the software, and is the picture of the process correct?

This question can be phrased as a core hypothesis, in a single sentence that can turn out to be wrong. For example: "If orders can be entered on a smartphone in under a minute, the field service colleagues will stop keeping paper notes." That is testable, and it also says what you do not need to build to run the test. Invoicing, reporting and permission management are not part of the test.

The smallest useful scope follows from the hypothesis. "Useful" is the decisive word here. A minimum that nobody can use day to day yields no insight, and users give it only the attention they would give a demo appointment. The core has to be able to carry real work, even if only in one slice: one team, one order type, one location.

It helps to weight the risks explicitly before the scope is set. The following chart shows such a weighting for a hypothetical project of this kind.

The alternative to a requirements specification is not giving up on planning but a different order. First the biggest uncertainty is cleared up with the smallest possible effort, then it is decided what gets built. This does not automatically save money. It shifts spending from assumption to insight, and that is the real gain.

A clickable prototype is the lightest stage. It consists of designed screens that can be linked together, without any logic or data working behind them. It is suited to checking workflows, terms and sequences, and it can be produced in days rather than weeks. It is not suited to judging load, data quality or everyday usability, because nobody works with mock-ups the way they would work with a real system.

A working MVP goes one step further. It stores real data, has a login and runs in daily operation, albeit with few functions. Anyone who wants to commission an MVP should therefore clarify from the start whether a clickable prototype is enough or whether the hypothesis can only be tested in live use. A combination usually helps: first the prototype for the workflow, then the MVP for the long-running test.

The other side matters too. An MVP approach is not the right choice everywhere. For heavily regulated processes, fixed standards, or replacing existing software with a precisely defined range of functions, a detailed functional specification can make sense. Even then, a small prototype for the riskiest screens is worthwhile.

Scoping starts with observation rather than a list of requirements. We would spend half a day on site, accompany two or three people at work and note down the workflow as it actually runs: with interruptions, questions and sticky notes. The result is not a document but a short list of moments in which today's solution fails.

The core is derived from these moments. As a rule of thumb, ask whether a slice delivers value on its own. Capturing an order and assigning it to an employee can be such a slice. Capturing an order but not yet invoicing it probably is too. Invoicing without capturing is not. This produces a cut through the process that contains a piece of end-to-end work, rather than a little of every layer.

Deciding what will not be built is an equal part of this. We therefore keep a short "not-yet list" of functions deliberately postponed, each with the reason. That way it stays clear that something was not forgotten but deferred, and the list later becomes the basis for planning the expansion.

Several expansion stages can be shown as layers that build on one another, each with its own learning goal.

A common objection is that an MVP is a throwaway product that later has to be rewritten completely. That is true if you build it that way. It is not necessarily true. What matters is where you save. You save on scope, appearance and special cases, not on the data model, access protection and traceability. A clean data model can be extended, a chaotic one can only be replaced.

In practice we rely on proven, widely used building blocks: a relational database, a web interface that runs on smartphone and computer, login through established methods, regular backups. We avoid custom-building solutions for standard problems such as password management or sending e-mails. That not only reduces effort but makes the transition to later expansion easier, because other developers know the building blocks.

The work runs in short cycles. A demonstration is followed by use by real users, then an evaluation and the decision on the next cut. A version goes into daily use after a few weeks, not only once all functions are finished. Traceability includes documenting every change in version control and letting the team try things out in a test environment before anything goes live.

A few deliberately chosen checks provide safeguards. The core workflows get automated tests so that later changes do not damage them unnoticed. For data, the same applies as for larger systems: backups must not only run but must have been restored once as a test. Everything else, such as a sophisticated permission concept, follows once the core holds up.

Hardly any question is argued as emotionally as this one. A fixed price promises security, time and materials promises flexibility, and both promises are only half true. A fixed price is reliable if the service is described precisely. The less clear the requirement, the more buffer the provider builds in, or the more dispute arises later over what was "included". The fixed price shifts the risk, it does not remove it.

Time and materials is more honest when the goal is not yet settled. You pay for work actually done and keep control. The price for this is discipline on your side: without a ceiling, regular status updates and clear prioritisation, a project can quietly expand. Anyone using it should set a framework, such as a budget per cycle followed by a decision on the next one.

A staged model has proven a good middle way. The test, meaning observation, prototype and first MVP, is agreed as a manageable package with fixed scope and fixed price, because it can be described in advance. The expansion that follows runs in cycles, each with a ceiling and a clear approval. That way there is an exit at every point, and the decision on the big budget is made with knowledge instead of hope.

Honesty also means admitting that this model has drawbacks. The total cost is not fixed at the start. If you need a fixed sum internally to approve the budget, you can state it as a range that narrows after the test. And a staged approach requires that you have time for feedback. Without it, even the best contract does not help.

In an iterative project, changes are the normal case, not a disruption. That does not make change management superfluous but necessary, because without rules flexibility turns into arbitrariness. A short list has proven its worth in which every change is recorded with reason, estimated effort and impact on schedule or budget, along with one person on your side who decides priorities. Several decision-makers with different wishes are the most common risk in such projects.

Acceptance also needs a different form. Instead of a single date at the end, there are acceptance criteria per cycle, worded so that they can be observed. "The software is user-friendly" is not one. "A new employee captures an order without help after ten minutes of instruction" is one. Such criteria can be checked in daily work and prevent disputes over readings.

Another special case is the existing data. If legacy data is to be migrated, it often only becomes clear during testing how inconsistent it is: duplicate customers, free text instead of selections, missing mandatory details. We recommend importing data early with a small extract, because otherwise the cleanup is underestimated. The same applies to interfaces to third-party systems, whose behaviour only becomes truly known in practice.

Finally, there is the case where the hypothesis turns out to be wrong. That is a good result, even if it does not feel like one. With limited effort you have learned that the planned path does not hold, and you can change course or decide against the project. For this you should define in advance how you will recognise it, otherwise every piece of feedback is read as confirmation.

An MVP approach improves the basis for decisions, not automatically the result. What you can expect is that the biggest wrong assumptions are noticed earlier than in a fully pre-planned project. Whether that ultimately saves money or time depends on the project, the team and the quality of the collaboration. We cannot responsibly give percentage figures for savings.

The benefit can be measured with indicators close to everyday work. These include the time for the core process compared with the previous way, the number of queries and corrections per case, the share of cases that actually arise in the system rather than on slips of paper or in spreadsheets, and voluntary use after the introduction phase. The current state should be roughly recorded before you begin, otherwise there is nothing to compare against.

Allow several weeks of observation before patterns show. The first days are marked by curiosity and teething problems; use only becomes meaningful once the novelty has worn off. That is another reason not to set the test too short. It is also helpful, after the observation phase, to talk to the users who avoid the system: their reasons often show more precisely than any statistic which assumption did not hold and whether it can be fixed by adjustment or only by giving it up.

What cannot be guaranteed is that the MVP will later grow into the complete solution without rebuilding, that all those involved will accept the software, or that the total price will stay below a certain mark. What can be promised is a transparent approach, honest status updates and the possibility to exit at defined points.

The most important idea is that clarity comes from use, not from description. That does not mean descriptions are worthless. A concise document with a target picture, core hypothesis, not-yet list and acceptance criteria has often proven a better working basis than a comprehensive requirements specification, because it records decisions without presenting assumptions as facts.

The second insight concerns involvement. Involving users early does not mean putting them in workshops but giving them something tangible and observing their reaction. Even a clickable prototype that a colleague uses for five minutes often delivers more than a day of requirements talks. It is just as important to ask not only the enthusiastic but also the sceptical, because their objections are usually more concrete and concern exactly the points where everyday work will later put the system to the test.

Third, every decision on scope should include a reasoned refusal. An MVP that can do a little of everything is not an MVP. Anyone who only adds functions and never removes any is building a requirements specification in code. A fixed rule helps: for every new function, name which assumption it tests and how you will recognise that.

A requirements specification is not a mistake, but it is often the wrong first step. If you are not sure whether the team will accept new software and whether the picture of the process is correct, a small, usable core is the cheaper way to find out. Anyone who wants to commission an MVP is above all buying a reliable answer to the question of what should really be built.

The next step is manageable. Write down in one sentence what should change in everyday work, and note how you would recognise it. Add three things you explicitly do not need yet. With this half page you can have a conversation that achieves more than a long document. We are happy to look at it with you and will say clearly whether an MVP approach suits your project or whether a classic functional specification is the better choice.