Case studies
Two systems in production, from the first schema to what they cost to run today. The second one is answering you right now.
Built for a client · anonymised
Two agents, the knowledge platform they learn from, the backend that survives being killed mid-job, and the measurement layer under all of it. One system, built in pieces over two years, still running.
5 systems inside it
Production · customer-facing
One chat window, two specialized agents behind it, each picking up the parts of the conversation that belong to it. When the brain feeding them goes down, the chat keeps working anyway.
Flagship · production
Two AI agents share one brain. It holds what the company knows, answers with citations, and takes in new knowledge through a review pipeline — so I can change how both agents behave without shipping a deploy.
Production · the plumbing
Kill the server halfway through a job and nothing gets sent twice, nothing gets lost, and the lock releases itself. Nobody puts this in a demo. It's the reason everything above it stays up.
Production · analytics
Their visitor numbers were running five to ten times too high — corporate link scanners the vendor's own bot filter never caught. I rewrote what every event means, rebuilt eight funnels, and got conversion measured against a denominator that's actually true.
Flagship · production
Making a content site legible to the assistants people now ask instead of searching — typed structured data on every page type, machine-readable endpoints, a named AI-crawler policy, and a frozen prompt panel that measures whether any of it worked.
3 write-ups, deliberately different arguments
Running on this site
The one you don't have to take my word for. Architecture, the tools it can call, the guardrails around them, and — the part nobody publishes — what it can't answer and what it does instead of guessing.
It is live — talk to it at /contact and try to break it. The write-up comes next, from the build log rather than from memory: every decision in it was written down the day it was made.
Also built
Built outside client work. Not case studies — one of those needs a system with enough life behind it to have gone wrong in an interesting way. These are here because it's where the stack gets tried before a client pays for it.
Solo · you're on it
The one thing here you can check without taking my word for it. A small pnpm monorepo — an Astro site and a React admin app sharing one token package and one component package.
Solo product
A pure, snapshot-tested compiler that turns a template's HTML plus a token manifest into a framework-specific design specification. Six targets, one function.
Solo product
A Turborepo monorepo — app, marketing site, admin SPA, four shared packages — with per-org billing and an EU-VAT-correct invoicing client written from scratch.
FAQ
Why the client isn't named, where the revenue numbers went, and which one to read first.
Because they have not agreed to be named yet, and that is the whole reason. Their numbers are theirs to publish, not mine, and that matters more than usual on pages carrying their internal metrics.
What is here is the method, the architecture and the figures that describe the measurement rather than the business. If they sign off later, the only thing that changes on these pages is a name.
Twelve years at one company, and the systems here were built across the last stretch of it. It is depth rather than breadth, and I would rather show you one system I can defend line by line than five I can only describe.
The work built outside that engagement is listed separately at the bottom of this page, marked for what it is.
Deliberately blank, and each empty tile names the exact report that would fill it. There is no verified revenue figure, no measured conversion lift and no hours-saved number for this system, because the clean before-and-after window does not exist and I have not sat down with the client's own order data.
Anyone claiming hard ROI for a system this young is selling you something. What can be shown is capability: work that used to depend on someone remembering now happens by construction.
Yes, and it is a better use of your time. On a call I will screen-share the live systems, the dashboards behind these figures and the commit history, which is more convincing than a number on a page you would have to take on trust.
For anything not written up yet, that is the only option — I would rather show you the real thing than make you wait for a page about it.
Depends what you are hiring for. If you want to know whether I can build the thing, start with the closed loop: the architecture, the reliability layer, and how learning gets from a finished conversation back into the agent.
If you want to know whether I can tell you it worked, start with the analytics one. If your problem is that assistants never mention you, start with the AEO write-up.
Next step
The published write-ups have seven of them between them. For anything not written up yet, I'll screen-share the real thing — schema, retrieval path, failure handling — rather than make you wait.