"Start with an MVP" is advice everyone accepts and nobody can apply, because it does not say what to cut. Two teams following it end up with completely different things: one with a beautiful shell that does nothing, another with a fragment that works but that nobody can use for real work.

One journey, all the way through

The rule we use: pick the single journey your business would notice if it stopped, and build that journey end to end — including the ways it goes wrong.

End to end is the important half. A first version covering ten journeys at sixty percent is unusable: every path leads to a wall, and your team must keep the old system running for the missing forty. A first version covering one journey completely replaces something real on day one.

Including the bad days matters too. A journey that only works when everything goes right is not finished — the failures are what your staff will meet on the first afternoon.

What goes in regardless

Three things are never phase two, however tempting.

Accounts, roles and permissions. Who may see what is structural. Adding it later means touching every screen twice, and the second touch is always dearer than the first.

An admin panel your team edits. If changing a price or a label requires a developer, you have bought a dependency, not a system.

Deployment that works. If getting a change live is an evening's work, the project slows down permanently, and the slowdown compounds.

What deliberately waits

Reports, usually — building them before real data exists means reporting on invented rows. Importing history from the old system, which is a project of its own and often better solved by running both for a month. A mobile app, when the browser would do for a year. And every screen belonging to journeys two through ten.

The test at the end of week eight

One question is worth holding a first version to: can somebody do their actual job in it, unaided, on real work? Not a demo, not a sandbox — a real order, a real customer, real money.

If yes, everything after that is improvement, and improvement can be funded from evidence. If no, then what was built is a document about a system rather than a system, and the next eight weeks will be spent arguing about which parts to finish. What goes into those first eight weeks, and what deliberately waits, is laid out on the web development page.

If you have not read it yet: when buying software is the smarter answer.