Why a lab?
Consulting is what I'm hired for. The lab is how I stay sharp at it.
Most of my work is fares, ticketing and retail for UK public transport — strategy through to delivered systems, in complex multi-operator environments. That work has a particular character: high stakes, long horizons, lots of stakeholders, and a strong bias toward being right rather than being fast.
The lab is the opposite end of the dial. It's where I get to be fast, build AI-first, and find out what's possible by making the thing rather than specifying it. Some of what lands here is genuinely useful. Some of it is play. None of it has to be finished to be worth showing.
An experiment doesn't have to ship to teach you something.
Keeping it separate from the consulting site is deliberate. Clients come to that site for a clear, senior, dependable picture of the work. They shouldn't have to wade through half-built prototypes to find it. And the experiments shouldn't have to pretend to be polished client deliverables to earn a place online.
So: two sites, one person. The consulting site is the finished work. The lab is the workshop it comes out of — and a standing reminder that the fastest way to understand something new is still to build a small version of it and see what breaks.
If something here grows up, it crosses over into real work. Everything else stays in the lab, where being unfinished is the whole point.