I build software that holds up.

I came to software engineering through QA, which means I was breaking systems before I started building them. That habit of hunting for 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 in 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 stayed the same: 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.