Case studies
What the work actually looks like.
Client names appear here only where we have permission. Where we do not, the work is described anonymised — because the architecture is the useful part, not the logo.
How an engagement runs
Four phases, and you can leave after any of them.
Architecture review
A working session with the engineers who would deliver it. We map the current estate, the constraints, and where it will break at the next order of magnitude.
Design
Data model, integration surface, security model, and release strategy — written down, reviewed with your team, and agreed before anyone builds.
Build
Delivered in reviewable increments against automated tests, in environments that predict production.
Run
Handover to your team with the pipeline, the tests, and the documentation. Or we keep running it. Both are fine; being unable to leave is not.
What you get in writing
The artefacts, not just the outcome.
Every engagement produces the same set of documents, and they are yours regardless of whether we continue together.
- Architecture decision record — every significant choice, with the alternative we rejected and why
- Data model documentation, including the 10x review and where the ceiling sits
- Integration contracts and failure-mode analysis for each connected system
- Security and access model mapped against your actual obligation
- Release runbook, pipeline configuration, and a rollback procedure that has been tested
Reference calls
Talk to a client instead.
Written case studies are marketing. If you are seriously evaluating us, ask for a reference call and speak to someone who has been through a programme with us — including, if you want, one that did not go smoothly.
Request a reference callBring us an architecture problem.
A working session with the engineers who would deliver it. No pitch deck.
Book an architecture review