I build the kind of software that has to keep working: backend services, event-driven pipelines, and the infrastructure they run on. My work sits at the intersection of software architecture, distributed systems, and cloud infrastructure — taking systems from whiteboard sketches to production traffic, and keeping them healthy once they get there.
Day to day, that means designing service architectures, building event-driven systems with tools like Kafka, hardening deployments on cloud platforms, and doing the unglamorous work that makes systems observable and operable. I care about performance as an engineering discipline: instrumented, measured, and improved — never guessed at.
Alongside consulting and engineering work, I build products and maintain open-source projects — usually tools that scratch an itch I hit myself. I write about what I learn on the blog.
How I work
Software decisions are trade-off decisions. My job is to surface those trade-offs early, put them in writing, and build systems where the consequences of being wrong are small and reversible.
Principles I keep coming back to
- Boring technology, exciting results. I reach for proven tools first. Innovation budget is spent where it changes the outcome, not where it makes a good conference talk.
- Measure before optimizing. Profiles, traces, and load tests before opinions. Most performance work is deletion, not addition.
- Design for failure. Every distributed system fails — the design question is how it fails, how fast you notice, and how easily it recovers.
- Operations are part of the product. A system nobody can deploy, observe, or debug is not finished. Runbooks, dashboards, and alerts ship with the code.
- Decisions belong in writing. Architecture Decision Records outlive meetings. Written trade-offs can be challenged; hallway decisions cannot.
Elsewhere
You can find my code on GitHub and my professional background on LinkedIn.
Want to work together? See how I can help or get in touch.