
Most architects eventually stop building. They move into advisory roles, draw target-state diagrams, and hand them to delivery teams. I took a different path. I believe the best architecture decisions come from people who still feel the consequences of those decisions in production.
That's not a philosophy — it's a practice. I maintain the TypeScript SDK for the Model Context Protocol. I review pull requests. I debug integration failures at 2am when a deployment goes sideways. And I think that's exactly what makes my architecture advice worth listening to.
I started where most engineers start — writing code alone, learning by breaking things. Early in my career I gravitated toward distributed systems and eCommerce, working across Magento, Salesforce Commerce Cloud, and eventually the composable commerce ecosystem.
That conviction came from watching too many technically elegant systems fail because nobody asked whether the business could actually operate them. I learned early that the architecture isn't the diagram — it's the set of decisions that let a business move at the speed it needs to.
At LiveArea, I led a team that grew to over 40 engineers across multiple enterprise eCommerce programmes. That's where I learned the hardest part of architecture: it's not designing the system, it's aligning 40 people around a shared understanding of why the system works this way.
As CTO at SpinUp Digital, I was responsible for a 45-person engineering organisation and delivered 8+ enterprise implementations. Every one of them reinforced the same lesson: the teams that shipped well weren't the ones with the most sophisticated architecture — they were the ones whose architecture was legible, change-tolerant, and honest about its trade-offs.
Today I focus on two things. First, helping enterprise teams navigate complex architecture decisions — re-platforms, migrations, AI enablement — with hands-on technical leadership. Second, contributing to the Model Context Protocol as a maintainer, shaping how AI agents interact with enterprise systems.
That's the through-line. Whether I'm defining a migration roadmap or reviewing a pull request, I stay close enough to the work to know whether the architecture is actually serving the people who have to live with it.
Whether it's a re-platform, an AI initiative, or a team that needs technical direction — I'm happy to have the conversation.
Get in Touch