From idea to MVP in 8 weeks: our delivery process explained

Eight weeks is our typical idea-to-MVP timeline. It is not a promise on every project, and it is not achieved by working faster — it is achieved by deciding earlier.

Weeks 1–2: scope, and the things we agree not to build

The first fortnight produces two documents: what the product does, and what it deliberately does not do. The second one matters more. Most overruns are not caused by slow engineering; they are caused by scope that was never written down and therefore never bounded.

We also identify the single riskiest technical assumption and test it in this window, not in week six.

Weeks 3–6: build in visible increments

Delivery runs in two-week cycles with something demonstrable at the end of each one. Demonstrable means running software you can click, not a status update. This is the mechanism that catches misunderstandings while they are still cheap.

By the end of week six, the core path a user takes through the product works end to end. It is rough at the edges, and that is correct at this stage.

Week 7: hardening

The edges get finished — error states, empty states, the things that only appear when something goes wrong. Performance is measured against a real dataset rather than seed data. Security review happens here, before launch, not after.

Week 8: launch and handover

Deployment, monitoring, backups and the handover session. The same engineers who built it put it live, which removes the translation layer where most launch problems originate.

What makes it slip

Three things, in order of frequency: decisions waiting on someone who was not in the room at scoping, third-party integrations whose documentation does not match their behaviour, and scope added mid-cycle without anything being removed.

The first is preventable by naming a decision-maker in week one. The second we now budget for explicitly. The third is a conversation, and it is better to have it than to absorb it quietly.