Konstantin Konstantinov

I've spent 15 years at the intersection of business strategy and software architecture — and I still write code every week.

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.

Career Arc

From solo developer to enterprise architecture

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.

Architecture serves the business, not the other way around.

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.

The best architecture is one that's easy to change.

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.

Don't hand over a target-state deck and disappear.

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.

Let's talk about your architecture challenge

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