The practice
Every phase produces something you can hold us to.
The parts of an engagement that decide whether it works get decided early, and they are mostly unglamorous. This is the whole of it — what happens, in what order, and what exists at the end of each step that did not exist before.
How an engagement runs
Five steps, in this order, for a reason.
The order is not a preference. An architecture decided before the exceptions are known is a guess, and a handover written in the last week is a document nobody can use. Each step is here because the one before it made it possible.
- 01
Discovery
We find the exceptions. Anyone can describe the happy path in a workshop; what determines whether the system works is the duplicate submission, the approver on leave, the record that arrives out of order, and the spreadsheet one team maintains because the last system failed to model something real. We go looking for those, with the people who do the work rather than the people who describe it.
What you get
A written problem statement, the constraints we will design against, and an explicit list of what we are not building.
- 02
Architecture
We decide the load-bearing things before we write code: where data lives and who may hold it, what happens when a dependency is down, which system is right when two disagree, and how the thing gets recovered. These decisions are cheap now and structural later — every one of them is a rewrite if it is made by accident.
What you get
An architecture written down, with each decision paired to the trade-off it makes. A decision with no recorded cost is a preference.
- 03
Build
In slices that reach production, not in phases that reach a demo. Each slice is a thin path through the whole system — interface to storage and back — so integration risk surfaces in week three rather than in month five. You see working software early and often, and you can change your mind while changing it is still cheap.
What you get
Working software in an environment you can use, from the first slice onward.
- 04
Instrumentation
The system ships able to tell you what it is doing. Not a dashboard added at the end — logging, metrics, and audit designed with the feature, because the question you will need answered at 2am is not one you can add later. If we cannot tell you why it did what it did, we have not finished.
What you get
Observability in place, alerting that reaches a person, and an audit trail that answers what happened to a record and who touched it.
- 05
Handover
We write for the engineer who has never met us, because that is who will maintain this. Documentation that assumes the author has left, a runbook someone has actually followed, and a recovery that someone has actually performed. Handover is a thing we do throughout, not a session in the last week.
What you get
Documentation, a rehearsed runbook, a recovery someone on your side has run, and a team that does not need us.
The standards
What we hold to regardless of the engagement.
None of these is a number. A coverage percentage averaged over engagements we have not run would be a statistic about a past we cannot evidence. These are commitments instead — they bind us going forward, which is the only thing a commitment is for.
Instrumentation
Every system we ship can answer what it did, when, and for whom, without a developer opening a database. Logging, metrics, and audit are designed with the feature rather than added after an incident.
Testing posture
We test the things that would be expensive to get wrong, and we are honest that this is a judgement rather than a percentage. Money movement, permissions, reconciliation, and the unusual cases get real coverage. Chasing a coverage number produces tests of trivial code and a false sense of safety.
Security review
Identity, permissions, and data custody are designed at architecture, not audited at the end. Dependencies are tracked, secrets are never in the repository, and access is granted and revoked in one place — so an audit is a report we run, not a discovery.
Documentation
Written for the engineer who has never met us. Architecture decisions with their trade-offs, a runbook for the things that break, and the reasoning behind the choices — because the code shows what, and the next team needs why.
Recovery, rehearsed
A backup is a file. A recovery plan is a thing someone has done and timed. Before we call a system live, someone has restored it into a clean environment and watched it come up.
Handover
The engagement ends with your team able to run and change the system without us. That is the deliverable. A dependency on us at the end is a failure we would rather not design in.
Discovery is where this starts.
Tell us what cannot go wrong, and we will tell you honestly whether we are the right people to build it. You will speak to an engineer.