Technical Debt by Design: How We Launched Our MCP Server
We built and launched an MCP server in months by deliberately choosing speed over perfection. Here's why accepting technical debt early was the right call, and how we knew when to pay it back.
Last year, our company embarked on a new journey to further unlock the potential of AI for our customers by creating dedicated teams focused on making our product AI-native. I earned a spot on the new team, and our mission was to develop an MCP server, a tool that enables AI assistants to connect with external systems and data sources through a standardized protocol.
Phase 1: Speed to Beta (August Launch)
The mission began at the start of June, and we initially had a soft launch set for August. Our goal was to release the first version in beta to a handful of customers. The vision was clear: release a server with a handful of tools, each solving a particular use case. This approach would help us gain traction and solidify our place in the enterprise sphere.
We chose Python and the Fast MCP framework to quickly reach our goal. Since this was a greenfield project, we started with zero code. We made a deliberate decision: go with the bare minimum for logs, monitoring, authentication, and infrastructure. This way, we'd have the time and capacity to build tools that delivered real value.
By August, we hit our target. The beta launch was a success. Our handful of customers were engaged, and the tools were solving real problems. Being practical had allowed us to gain customer interest early on.
Phase 2: Post-Beta Expansion
After the success of the beta launch, new goals emerged. We reflected on what to do next and the direction became clear: deliver more value by introducing additional tools, give customers the option to use subsets of tools, and improve existing tools based on the limited feedback we received.
As you can imagine, technical debt remained an afterthought at this point. But this was intentional. Time was of the essence. We still set aside some time for improvements, but we capped it to maintain focus on tool development and customer value. Over the next few months leading up to our official November release, we stayed laser-focused on building features that mattered to customers.
Phase 3: Official Release and Paying Down Debt (November)
In November, we officially released the MCP server. At this point, we knew we'd opened the floodgates, much more feedback would come our way soon. But before that wave hit, we had a brief window to address the technical debt we'd been carrying. Our beta customers had been patient with the rough edges, but we knew a broader audience would expect more polish.
We started working on the missing pieces: monitoring, improved logging, and introducing coding standards. With the sweat and hard work we poured into the MCP server, we managed to get the service into decent shape. It wasn't perfect, but it was much better, and it gave us confidence going forward.
This was a crucial step. As engineers, we long to work on interesting projects, but we also strive for a clean codebase. It's no fun when you know things could break at any moment.
Phase 4: Scaling Challenges (January 2026)
By the end of January 2026, we saw adoption increasing, which was great news. But as the weeks passed, a problem emerged. By late March, we reflected and noticed how unsustainable our current development approach had become. We'd reached a tipping point. We were spending more time fixing or trying to fix tools than improving the overall service or addressing other teams' needs.
This realization sparked the MCP 2.0 idea. We defined where we wanted to go, what to prioritize, and how we would achieve our goals. It was time for another deliberate shift. Since May, we've been making adjustments toward this vision. As before, not everything can be done at once, but identifying crucial points early on will help us address the scaling challenges.
The Lesson: Pragmatism Over Perfection
As you can see, our journey was intense and full of shifts and pivots. This is the message I want to bring across. We never prematurely optimized things, but rather evaluated at each step what was most important.
Looking at it in hindsight, you could point out our lack of proper observability, authentication, and other technical debt. But it's easy to point it out at this stage, now that we know how the project and adoption evolved. As Thucydides wrote, "After the event, even a fool is wise." It's easy being smart about the past when we didn't have that information at the time. And who's to say we would have reached the same outcome if we'd pushed customer value aside?
Therefore, it was the right approach for us. At each stage, we reflected and adjusted. This is what software engineering is about — making pragmatic decisions even when they might hold you back down the line, knowing you can iterate and refactor as you learn. We deliberately made these choices, stayed practical, and now we reap the benefits.
What's your approach? Do you invest in quality upfront, or do you prioritize speed and iterate based on real feedback? I'd love to hear how you balance speed with quality in your projects.
Published by...
Jernej Klancic
Visit author page