I build software that holds up.

I came to software engineering through QA — which means I've been breaking systems before building them since day one. That paranoia about failure modes, edge cases, and the scenarios that only show up under load became the foundation everything else sits on.

Over the years I've shipped production systems across startup environments that don't tolerate much margin for error: HIPAA-compliant healthcare platforms, SOC-2-ready financial infrastructure where transactions are irreversible, and high-availability systems with hard SLAs. The stacks varied — Ruby, Elixir, Node, PostgreSQL — but the problems were consistent: scale, reliability, compliance, and knowing what's broken before the users do. I default to self-hosted tooling for observability and analytics wherever it's practical — your users' data shouldn't be a third-party's free lunch.

What I write about is what I'm actually thinking about while I'm building: the architectural decisions that weren't obvious, the performance bottlenecks that took too long to find, and the patterns that hold up when things get complicated.