Production is the only real test
A system that works in a demo has proven almost nothing. I design for the conditions that actually break things — real traffic, real edge cases, real cost.
About
Fifteen years of shipping systems that have to stay up.
I'm a software architect who spent a career making production systems reliable. The AI work I do today rests on that — it's the same discipline, pointed at a harder, newer problem.
I build the parts of AI that don't show up in the demo. Over fifteen years I've worked on cloud-native infrastructure, distributed backends, and the APIs that hold real products together. That's the foundation. What changed is where I point it.
Today my focus is AI and agent systems — LLM applications, RAG pipelines, and multi-agent architectures. Not the version that works once on a curated example, but the version that holds up under real production load: accurate enough to trust, observable enough to debug, and cheap enough to keep running. That's a different problem from getting a model to respond, and it's the one I'm interested in.
That AI work sits on a foundation of Kubernetes, AWS, and the DevOps and MLOps discipline needed to operate AI reliably. The reason I can take an AI system to production is that I've spent years operating everything else in production — the boring, unglamorous machinery that decides whether software is a feature or a liability.
I work independently, directly with founders and engineering leaders, on the hard parts of moving AI from prototype to production. No agency layers, no handoff to a junior team — when you hire me, I'm the one doing the work.
Operating principles
How I think about the work.
These aren't slogans — they're the defaults I fall back on when a decision is genuinely hard.
Boring infrastructure is a feature
The most valuable systems are the ones nobody has to think about. I'd rather ship something predictable than something clever that needs babysitting.
Leave the team stronger
I write code and architecture your team can own after I'm gone. An engagement that leaves you dependent on me has failed, even if the system works.
Honest about trade-offs
Every architecture is a set of trade-offs. I'll tell you what we're giving up and why — including when the right answer is to do less, or nothing yet.
Working together
How an engagement actually runs.
- Independent
- You work directly with me. I take on a small number of engagements at a time so each one gets real attention — this isn't an agency and there's no bench to hand you off to.
- Collaboration
- I embed with your team rather than working in a vacuum — in your repos, your channels, your standups when it helps. Async-friendly and used to working across time zones from US Central.
- Communication
- Plain language, no jargon-for-its-own-sake, and a written trail of the decisions that matter. You'll always know what I'm working on and why.
- Confidentiality
- I don't show client work — no logos, no case studies, no anonymised war stories. The discretion I extend to past clients is the same I'll extend to you.
- Scope
- We agree on what "done" means before we start, whether that's an advisory cadence, a fractional commitment, or a scoped delivery. Clear edges make for a good working relationship.