I’ve spent close to two decades working on systems where failure is visible and mistakes are expensive. VoIP, real-time systems, backend infrastructure, and the tooling that grew up around them. Most of that time went into learning where systems bend or break, and why an idea that looked simple in a design review turns complicated the moment it has to hold up under load and keep holding for years.

I care about clarity in code and restraint in design. Minimalism here is a discipline, not an aesthetic. I choose fewer abstractions and even fewer promises, because every promise a system makes is one somebody has to keep long after the person who made it has moved to another team.

This site is where I think in public, slowly. The writing follows whatever I’m working on, which usually means architectural decisions and the trade-offs sitting underneath them, or failures that turned out to be worth understanding properly rather than patching. Some pieces are technical. Others are closer to notes I wanted to keep somewhere I would find them again.

I don’t write tutorials, unless they’re quirky and non-obvious, and I don’t publish hot takes at all. If something appears here it’s because I think it’ll still be worth reading long after the current tools are gone and the noise has moved somewhere else.

The common thread is longevity. Work you can reopen years later without embarrassment is worth doing, and most of what I write is an attempt to understand how a system arrives there instead of becoming the file nobody wants to open.

If you find something useful here, say Hello.