The six stages, in practice.
Published 21 October 2026
Why a method at all
Complex software rarely fails because a team cannot write code. It fails in the gaps: between what the business needs and what was specified, between a design and its implementation, between a working demo and a system someone can run at three in the morning. A method is a way of closing those gaps on purpose.
We organize our work in six stages: Understand, Design, Build, Validate, Operate and Improve. None of them is new. What matters is that each one produces something a person outside the team can read, challenge and reuse, and that skipping a stage is a conscious decision rather than a default.
This article describes what each stage is for, what it should leave behind, and why we resist treating the sequence as a waterfall.
Understand and Design: decide before you build
Understand is the stage most often compressed, because it feels like delay. It is also where the cheapest mistakes are made. The output is a written description of the problem: who is affected, what must not break, which constraints are fixed and what done means for the business. If two stakeholders describe the problem differently, we want to learn that now.
Design turns that description into the smallest architecture that removes the main constraint. We record the options we considered and the ones we rejected, because the reasoning is more reusable than the diagram. A decision record of half a page is usually enough: context, decision, consequences.
Both stages are cheap to repeat and expensive to omit. They also create the vocabulary the rest of the work uses, which matters more than it sounds when several teams are involved.
Build and Validate: one loop, not two phases
We treat building and validating as parts of the same loop. Work is cut into increments small enough to review in one sitting, and each increment arrives with the checks that show it does what was agreed: automated tests, contract checks at integration boundaries, and review by someone who did not write it.
Validation is not a final inspection. A check at the end can only report that something is wrong, when it is already costly to fix. Placing checks early and close to the risk lets a failure point to a cause. When a check can never fail, it is not validating anything, and we say so.
Validation also covers the properties that demos hide: how the system behaves under load, with bad input, with a dependency down and with the permissions a real user has.
Operate and Improve: the system lives in production
A release is the beginning of a system's working life. Operate is about making that life manageable: a release path that can be repeated and reversed, monitoring tied to what users experience, alerts that reach someone who can act, and runbooks for the incidents we can foresee.
Improve closes the loop. Production produces evidence that no workshop can: which features are used, which failure modes occur, where the team loses time. We feed that back into Understand for the next decision, whether it is a refactoring, a new capability or a decision to stop investing in something.
If the people who own the system cannot operate and improve it without us, the engagement is not finished. Handover is part of the scope from the first conversation.
How we use the stages
The stages are not a waterfall. They repeat at different scales: a whole programme goes through them, and so does a single feature. An engagement may start at any stage. A technical assessment is mostly Understand and Design. A project delivery covers the full sequence. A partnership may spend most of its time in Validate and Improve.
What stays constant is the discipline of leaving something durable at each stage, and of writing down what we do not know yet.
If you are considering working with us, a useful first question is simply: which of the six stages is the weakest in your organization today?
