Proof, Not Theatre
No logo wall. The shape of the work.
A logo grid proves that money changed hands, and little else. Client names, figures and screenshots stay behind NDA here, so what this page sets out is the kind of system we take on, the standard we hold it to, and how you can test both.
Engagement Profiles
Six kinds of system we take on.
Each profile describes work we are built to deliver: the constraints that decide the design, the parts that usually go wrong, and where the engineering effort actually lands.
- 01
Retrieval-grounded support agent
An agent that answers from your own documents and ticket history, cites the source behind every claim, and hands over to a person the moment confidence drops. Your team owns the evaluation set and runs it.
- 02
Multi-tenant operations platform
Scheduling, mobile job capture and billing for crews spread across sites. Tenancy isolation, roles and audit trails land in the first migration, because retrofitting them later costs more than the feature ever did.
- 03
Core system replacement, in stages
Replacing software the business depends on every working day. Old and new paths run side by side, one workflow moves at a time, and the rollback is rehearsed before anybody needs it.
- 04
Integration layer across ERP and CRM
One operations layer between an ERP, a CRM and supplier APIs, reconciling the records each system claims to own. Failures surface as replayable events with an owner attached, so nothing dies quietly in an inbox.
- 05
Commerce platform rebuilt headless
Catalogue, search and checkout decoupled from the storefront, so merchandising and content stop queueing behind engineering releases. Page weight and structured data are trading work here, and they get planned like it.
- 06
Reporting on a modelled warehouse
Dashboards fed by modelled data instead of a chain of exports, so two departments stop arguing about whose number is correct. Metric definitions live in version control beside the queries that produce them.
Due Diligence
What we can show you, and when.
Confidentiality is part of the job for most of the people we work with, so we do not trade it for marketing copy. Plenty is still open to inspection before you sign anything.
- 01
A named reference, on a call
When a conversation turns serious, we ask a client whose system resembles yours whether they will speak to you. If one agrees, you get their engineers and your own questions — no script, no curated quote.
- 02
An architecture walkthrough
We screen-share a running system and go through the schema, the service boundaries, the failure modes and the decisions we would make differently today. What we cannot name is redacted, never fictionalised.
- 03
Code your engineers can read
Where the client owns the licence and agrees, we open repository access or a representative extract. Your developers judge the tests, the naming and the documentation for themselves.
- 04
A paid pilot before a programme
If evidence matters more than argument, we scope one self-contained piece of the real problem, build it, and let the result decide whether the larger programme goes ahead.
Case Studies
How the first one will read.
When a client approves a case study, it will be written the way we would want to read one. The brief as it actually arrived, including the parts that turned out to be wrong. The decision we argued about internally, and why one option won. What was measured, how it was measured, and who did the measuring.
Until one is signed off, this page stays empty of proof rather than filling up with borrowed credibility. A logo we cannot explain, or a percentage nobody can trace back to a query, tells you nothing about whether we are the right team for your system.
Straight Answers
The questions this page invites.
Why not publish an anonymised case study now?
The recognisable details are the useful ones, and they belong to the client. We ask permission first and publish only what comes back approved.
Who owns the code you write?
You do. We write it into the contract: source, infrastructure definitions and documentation are yours, including everything you would need to hand the system to another team.
Can you take over a system someone else built?
Often, yes. We read it and run it before promising anything, then say plainly which parts are worth keeping and which are cheaper to replace than to repair.
What if you have not worked in my sector?
Regulation and vocabulary we learn from your team during discovery. The structural failure modes — integration, data ownership, migration — look much the same from one sector to the next.
Start with the system you are worried about.
Describe what it has to do and where it hurts now. We will tell you which profile it resembles, what we would not build, and which questions to put to us before you decide.