Reference architectures
What a typical engagement looks like
Last verified: October 2026· reference architecture
These are the engagements we run. The starting state, the work week by week, the deliverables, the end state, and the ownership boundary. Not a customer story — we publish a reference architecture so a buyer can pattern-match against their own situation before a 30-minute technical call.
Reference architecture: a 6-week LLM cost engagement
A typical 6-week LLM cost optimization engagement — the week-by-week plan, the deliverables, the end state, and what the buyer owns when the engagement ends.
Reference architecture: a 6-week AI coding workflow rollout
A typical 6-week AI coding workflow rollout (Claude Code + Cursor + Copilot) — the week-by-week plan, the deliverables, and what the team owns at the end.
Reference architecture: a 4-week MCP server build
A typical 4-week MCP server build (per server) — the week-by-week plan, the deliverables, the security defaults, and what the team owns at the end.
Why these are reference architectures, not case studies
Most consulting websites carry named case studies with a number attached. Ours do not, for a deliberate reason: the engagements we are proudest of are with teams whose AI spend, codebase quality, or security posture is not something they want published, and the ones we could publish would be a biased sample chosen for how well they read. So these pages describe engagement shapes instead — the actual week-by-week structure, deliverables, and end state of the work we do — with no client names and no outcome figures we cannot substantiate.
What that costs you as a reader is the emotional pull of a story. What it buys you is something more useful when you are actually scoping: a realistic picture of how the weeks are spent, what gets produced, what we need from your side, and where these engagements typically hit friction. A named logo tells you someone else bought it. A week-by-week plan tells you what you would be buying.
Read them as a template rather than a promise. Real engagements deviate — an audit uncovers something that reorders the plan, an integration takes longer than scoped, a stakeholder change moves the goalposts — and the reference architecture is the shape we start from and adjust, not a contract. Where a page states a range, it is drawn from our own engagements and labelled as such; it is not a benchmark and should not be quoted as one.
If you want to talk to someone who has worked with us, ask on the call. References are given directly to serious buyers, with the client's permission, rather than published as marketing. That is slower than a testimonial carousel and considerably more informative, because you get to ask your own questions rather than read the ones we chose.
How to read these before a scoping call
The most useful preparation is to read the week-by-week plan for the engagement closest to your situation and mark the points where your organisation would slow it down. Access approvals, security review, the one system nobody has credentials for any more, the stakeholder who is on leave in week three. Those are the real variables, and a scoping call that starts from them is dramatically more productive than one that starts from what we do.
It is also worth reading what the client is expected to supply. Every engagement here assumes some access, some time from an internal engineer, and a decision-maker who can approve a direction without a committee. Where any of those is not available the shape has to change, and knowing that in advance saves a week of discovering it.