About

Currently: Principal Engineer at YuLife. Architecture and delivery across partner, client and member-facing systems, plus the company-wide AI adoption programme.

I've been building software professionally for long enough to have done it from both ends. I've started things, two of which got far enough to be worth naming: thestudentjob.com, and then Urban, a wellbeing marketplace. Founding teaches you an unreasonable amount about scope, mostly that almost everything you were sure was essential turns out not to be, and the thing you nearly cut is the product.

These days I'm a Principal Engineer, which covers a lot of ground. There's technical direction and delivery on partner, client and member-facing work: system architecture, integration design, and the cross-team coordination that turns a good plan into something that actually ships. There's the AI adoption programme: agent runtimes, sandboxing and credential isolation, developer tooling, and the unglamorous work of getting all of that into the hands of people with real jobs to do. And there's a fair amount that sits under neither heading. What runs through all of it is enablement: the role exists to help the people doing the work, so most of what I do is make someone else's next step easier. The judgement is nearly always the same trade, between the pace the business needs and the risk that pace carries, and the job is to find the version where you don't have to pick one.

How I work

Four things that keep coming back, and where I've landed on each.

Building against systems you don’t control

A lot of my work sits on integrations where the data contract belongs to somebody else. The schema is theirs, the failure modes are undocumented, and you find out about a breaking change when it breaks. So I design as though that's guaranteed rather than possible: treat everything crossing the boundary as untrusted input, validate it at the edge where you can still say something useful about what arrived, and never let a partner's bad day turn into silent data loss on ours. The habit that pays for itself most often is making failure loud. An integration that degrades quietly will be discovered by a customer; one that fails visibly gets fixed the same morning.

Enabling delivery across teams

The technical design is usually the easy half. The hard half is that a piece of the work sits with each of several teams, all of whom have their own quarter to think about, and my job is to help them get there rather than to hand a plan down. So I work with the business on what the outcome actually needs to be, and alongside the delivery teams on what it takes to build it. Most of my time goes on making the critical path legible, so a blockage is obvious to everyone before it bites instead of surfacing in a status meeting two weeks late. In practice that means sequencing and clearing the way: deciding what ships in what order so each team can keep moving, and going and removing the thing that's about to stop them.

Making a new capability safe enough to hand to everyone

There's a long gap between a thing working and a thing being safe to give to an entire organisation, and most of the interesting work lives in that gap. Sandboxing, so a mistake is contained. Credential isolation, so the blast radius of a leak is one system instead of all of them. Defaults that are right for the person who won't read the docs, because that's most people and they're not wrong to be. And guardrails set carefully enough that the thing is still worth using, because a capability locked down into uselessness gets routed around, which is strictly worse than not shipping it.

What I’m like to work with

I'm drawn to the invent-and-decide phase: generating a wide set of options, spotting which ones are the same option wearing different clothes, and filtering fast. That filtering is instinct as much as analysis, so it's worth arguing with. I'm good in the ambiguous part, and I'd rather be handed a problem than a specification. The flip side: my energy dips once the direction is set and the work becomes execution. I know that about myself, so I build for it: get the shape right, write it down properly, and make sure the finishing doesn't depend on my enthusiasm holding.

Outside work

I 3D print, mostly things the house turns out to need, designed through a pipeline where Claude writes OpenSCAD, renders it, looks at the render and adjusts. Parametric CAD suits that loop far better than most of what people point models at.

The rest of my tinkering goes into Home Assistant. Most of it is unremarkable; the exception is an ESP32-S3 wired into a Big Mouth Billy Bass, which is now a voice assistant that flaps at me. There's also a boiler that only listens to 433MHz, which I dealt with accordingly.

More detail on the career side is on LinkedIn.