Phases
05
Delivery cadence
Two-week increments
First decision gate
End of Prove
Engagement ends
On handover, not on budget
Each phase has an exit question. We do not move on until it has an answer we can defend — and 'stop here' is always one of the permitted answers.
1–3 weeks
“What is actually the problem, and how will we know if we solved it?”
We resist the brief long enough to test it. Most engagements arrive as a proposed solution; the work of the first weeks is separating that from the underlying problem and agreeing what evidence would count as success.
In practice
3–6 weeks
“Does this work on our data, in our environment, at our constraints?”
A thin but real slice, built in your environment on your data. Not a demo on synthetic inputs — a narrow vertical cut through the whole architecture, which is the only thing that surfaces the integration and performance problems early enough to matter.
In practice
Two-week increments
“Is it getting better, and can we see it?”
Working software in your environment every two weeks. Your engineers are embedded in the team from the first increment, not briefed at the end — because the handover starts on day one, not at the close of the engagement.
In practice
2–4 weeks
“What happens on the worst day?”
The phase most programs skip and most incidents come from. Before anything carries real load we deliberately try to break it — security, failure modes, recovery, and the operational reality of the team who will hold the pager.
In practice
4–8 weeks, tapering
“Can your team run this without us?”
We reduce our own involvement on a published schedule. Success is measured by your team's independence — the engagement ends because it is finished, not because the budget ran out.
In practice
A five-phase process is easy to publish and hard to honour. These are the structural choices that make ours survive commercial pressure.
The people who recommend it are the people who build it.
There is no handoff from a strategy team to a delivery team, because they are the same team. It is the single structural reason our estimates hold up: nobody in the room is insulated from having to execute what they proposed.
No reseller margin. No platform quota.
We earn nothing on the licenses you buy, so our recommendation is not shaped by what we would make on it. That is what leaves 'buy rather than build' and 'stay where you are' genuinely available to us as answers.
Controls are architected in, not bolted on.
Regulatory posture, data residency and the control environment are settled during design. Retrofitting them onto a working system is the most reliably expensive thing we see in this industry.
Cost per transaction is a design constraint.
Unit economics are modeled before the architecture is fixed and tracked in production afterwards. A system that works beautifully and cannot be afforded at scale has not been engineered — it has been prototyped.
Our objective is your independence.
Your repositories, your cloud accounts, your documentation, your people trained to run it. No proprietary runtime, no black box, no dependency engineered to keep us on the invoice.
Seniority over headcount, always.
Engagements are staffed with practitioners who have built the thing before, not with a pyramid of juniors under a partner who appears at steering committees. It is a deliberate constraint on how fast we can grow.
We do not list technology strategy as a capability, because a recommendation from people who will not build it is the failure mode we exist to remove. Advisory work runs through every engagement instead.
A sequenced, costed plan connecting business objectives to what engineering actually does next quarter — with the investment case a CFO can read and the trade-offs stated rather than buried.
Raising the throughput of the teams you already have, usually the highest-return intervention available. Delivery-flow diagnostics, DORA instrumentation, platform investment cases and team topology.
Every recommendation carries its assumptions, its alternatives and the conditions under which it would be wrong. You should be able to challenge it, and the people who wrote it will be in the room when you do.
Diagnostics are fixed price. Build teams are time and materials against a published rate card. We do not quote fixed price for work whose scope we cannot yet honestly define — that pricing model only ever produces a fight later.
Most engagements start with a short, fixed-scope diagnostic — three to four weeks, a written recommendation, and a costed path forward. If we are not the right firm for it, we will say so and point you somewhere better.