How we run an engagement
It starts with a two-week discovery that can honestly end the engagement. That is the point of it.
The TechBlueprint framework
Four phases. Each one ends with something you own, whether or not you continue with us.
Diagnose
We read the code, the data and the incident history, and sit with the people who run the system. Two weeks. You come out with the real problem, which is often not the one in the brief.
You getA findings document and a risk register
Blueprint
The architecture, the order the work happens in, and the numbers we agree to be judged on — all settled before anything is built.
You getArchitecture decision records and a costed roadmap
Build
Two-week increments, each ending in something running. Testing, security and deployment sit inside the pipeline, so nothing waits for a hardening phase.
You getWorking software in production, every two weeks
Scale
We harden it, measure against the numbers agreed in Blueprint, and hand it over with the documentation your team needs to run it without us.
You getRunbooks, documentation and a team that can operate it
What to expect from us
When we would tell you not to start
If nobody can say what success would measure, if the person who owns the system will not be in the room, or if the timeline only works when nothing goes wrong — you hear it in week two, while stopping is still cheap.
Working software every two weeks
Every two weeks something runs that you can click, test and argue with. Nothing important lives only in a deck.
We stay after launch
The ninety days after go-live are inside the engagement. That is when real usage finds the things a test plan never does.
