Approach
How the work runs
Engineering is mostly decisions. This sequence exists so the consequential ones are made early, deliberately, and with the organisation in the room.
The stages below are not a fixed schedule and not a proposal template. They describe the order in which understanding has to accumulate before it is safe to build. On a small engagement they may take a fortnight; on an institutional system they may run for the length of the work.
The stages of an engagement
Understanding
We start with the operation, not the software.
What the organisation does, who is accountable for what, where information originates, which obligations are fixed, and where the current arrangement is quietly costing time. Much of this is written down nowhere, which is why it is a stage of the work rather than an assumption made before it.
Output
A written account of the problem, the constraints, and the shape of a system that would resolve it.
Architecture
Structure is settled before the code that depends on it.
Boundaries between components, the data model, integration surfaces, permissions, failure behaviour, and the order in which parts can usefully be delivered. Choices are recorded with their reasoning, because the reasoning is what a future engineer actually needs.
Output
An architecture the organisation can read, and a delivery sequence that produces something usable early.
Engineering
Built in reviewable increments against a defined architecture.
Strongly typed, tested where tests carry weight, and reviewed by an engineer who did not write it. The people who designed the system build it, so intent is not lost in a handover halfway through.
Output
Working software, delivered continuously rather than revealed at the end.
Validation
Correctness against the real cases, not the convenient ones.
The awkward record, the concurrent edit, the month-end load, the user on a poor connection. Performance, accessibility and resilience are checked as requirements, on the same footing as function.
Output
Evidence that the system behaves under the conditions the organisation will actually create.
Deployment and evolution
A system that ships is a system that starts changing.
Deployment is engineered rather than performed once: repeatable, observable and reversible. Handover assumes the organisation will outlive the engagement, and is written for the engineer who arrives two years from now.
Output
An operating system in production, with the documentation and access required to own it.
The first stage is a conversation.
Understanding begins before any engagement is agreed. If the problem turns out to be better solved another way, that is a useful outcome.