Work

Things I've built, migrated or repaired — what the problem actually was, what decided the design, and what the result does and doesn't prove.

These are systems I've built, migrated or repaired. Each page says what the problem was, what I did about it, and what it doesn't prove. No invented outcomes. Where something is still a pilot, or I don't have a measurement, the page says so.

Where the code can be public it is, and those projects have their own pages in the catalogue. Where it belongs to somebody else, the case says what changed for them and stops there.

The work tends to come in a few shapes:

  • a platform that had to keep serving while I replaced it piece by piece, with the running system as the reference for what "working" means;
  • a directory or marketplace where nothing goes live until it has been reviewed, and duplicates, media processing and rollback are one operation;
  • a data product built from official sources, where every published fact keeps the source behind it and there is a way to correct it;
  • pipelines that stay private: model endpoints, prompts, credentials and generated media never leave infrastructure the client controls;
  • a migration I'd trust because the rows reconcile and the checksums match, not because the cutover happened.

Every case page has the same four things: the problem in the words of whoever had it, the constraint that decided the design, what I built, and what it doesn't prove. If I can't write that last one, the case isn't finished.

I'm publishing these one at a time as I finish reviewing them, so a project can show up in the catalogue before its case page does. Until then, the catalogue page is the one to read.

Work pages

Have a system like this?

Describe the workflow, the data or the system you need built. Scope and any quote are handled privately after the enquiry.

Discuss your project

Published