Build an MVP first or build the whole thing? Do the arithmetic, not the vibe

Everyone advises building an MVP first. That advice is right most of the time and expensively wrong in a few specific cases. This is about both.

What an MVP actually is, and is not

An MVP is not "a reduced version". It is the version that is enough to answer a question you do not yet know the answer to.

If you cannot state that question in one sentence, you are not building an MVP — you are building software with missing features, which is a different thing.

A good question: "will salespeople enter orders on a phone at the customer's site, or will they still write on paper and key it in at the end of the day?" That is a question about behaviour, unguessable, and answerable with something small.

A fake question: "will the software work?" You do not need an MVP for that.

When phasing is right

You do not know how people will use it. The number one reason, and sufficient on its own. Every internal tool meets this: the process on paper and the habit in practice are not the same.

Your business is changing. If you have just opened a second branch or changed how commission is calculated, freezing the process into software now freezes something that is still moving.

You need something visible to convince other people. A running build after six weeks persuades a board better than a forty-page document.

Budget arrives quarterly. Phasing gives you a sensible stopping point at each boundary rather than one large commitment.

When phasing costs more

The part few people mention, and it is real.

When the data foundation has to be rebuilt between phases. A concrete case: phase one serves one branch, phase two adds many. If phase one did not model multiple branches from the start, phase two is a rewrite, not an addition. The combined cost runs 30–50% above doing it once.

The fix: design the data for the destination, build the interface for today. The tables carry a branch column from day one even though the phase-one interface never offers a branch choice. The extra cost is close to nothing, and it saves you the rewrite.

When the process is an indivisible block. Some workflows are useless in half. A payroll system that records attendance but cannot yet calculate pay gets used by nobody — they keep the spreadsheet running alongside, and you are paying for software nobody opens.

Test it with one question: after phase one, can anybody abandon the old way? If not, do not call it phase one; it is part one of a block.

When switching costs are high and get paid twice. Training forty staff twice, migrating data twice, running in parallel twice. With a large team those costs exceed the savings phasing was meant to produce.

The three-question test

1. After phase one, can anyone drop a manual task? No → do not phase it the way you are planning.

2. Does phase two require changing phase one's data structure? Yes → design the data for both now, even while building only phase one's interface.

3. Is there a question about user behaviour you genuinely cannot guess? Yes → phase it, and shape phase one around exactly that question.

The middle path we usually take

One phase, narrow scope, complete enough to replace something.

Concretely: pick one whole workflow, build all of it, build it well. Not half of three things — all of one thing. After four to eight weeks a real person abandons a spreadsheet, and you have real data to decide what comes next.

This differs from an MVP in that it is not a trial; it is finished software for a small scope. And it differs from "build it all" in that you have not committed to the other five workflows.

Our service runs this way by default, and during scoping we will actively push you to cut — usually to cut user roles, because that is where the largest savings are.

One thing worth remembering

The most expensive wrong decision is not MVP versus everything. It is phasing without designing the data for the destination — because then you pay twice for the same thing and get none of the benefit of phasing.

When you discuss scope with anybody, ask this: "will phase one's data structure hold phase two?" A shop that answers in detail has thought about it.