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.

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 — three years, incrementally, 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. 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. Latency budgets, cost ceilings, exactly-once accounting over at-least-once delivery, and a strict line between what the model perceives and what the system decides. 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 dozens of services; bespoke builds for a single client and products, which is where I do my best work — you can see the whole problem and own the solution end to end.

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 something here resonates, or you have a problem worth solving: [email protected]