About

I see systems everywhere — in code, in organizations, in processes. The instinct is always the same: understand how something actually works, then figure out how to make it work better. Software is where I apply it, but the mindset came first. Most engineering problems aren't solved by patterns. They're solved by understanding constraints, sequencing change, and making the right trade-offs.

What I'm good at is changing systems that can't stop running. Over the past few years I've taken a fintech platform from a monolith to an event-driven distributed system, incrementally and without ever taking production down. That work is less about the target architecture than about sequencing: what moves first, what keeps working while it moves, and which decisions you're allowed to defer. A surprising amount of engineering is deciding which problems not to solve yet. The interesting parts were never the diagrams. They were the consumers that had to keep working against two versions of the world at once.

I also care about the parts nobody puts in a design doc. Build and deploy times. Whether observability is worth what it costs — I built a stack, watched the bill, and rebuilt it on OpenTelemetry and Prometheus. Whether a new service inherits good defaults or starts from a blank repo. Standards that live in a template get followed; standards that live in a document don't.

Lately the problem I find most interesting is applied AI — specifically, holding a non‑deterministic component to the same standards as everything else. I built a document verification pipeline where deterministic extraction runs first and a model only handles what it can't resolve, so most requests never reach one. The interesting part wasn't introducing AI into the system. It was deciding where it belonged, what it was allowed to decide, and where determinism had to begin again. The model reports. The code decides.

I've worked across a wide range of systems: on-premise, where I installed the servers I'd later run things on, and in the cloud; monoliths and ecosystems of hundreds of services; bespoke builds for a single client and products. I do my best work on products, where you can see the whole problem and own the solution end to end. The environments changed. The engineering questions rarely did.

This site is where I write up the parts of that work that don't fit in a design doc: what actually broke, what the fix cost, and what I'd do differently. No frameworks-of-the-week, no motivational takes — just production notes. If that's the kind of engineering you're interested in, you'll probably enjoy the rest of the site.

If something here resonates, or you have a problem worth solving: [email protected]