We Rebuilt Our 15-Year-Old Platform in Four Months (case study)

Instead of fourteen months and CZK 4.3 million. This is how the full AffilBox rebuild was delivered.

In short

• A complete replacement of a SaaS platform that had been running and growing for 15 years
• 4 months instead of an estimated 14+
• Roughly 80% lower development cost against a conventional estimate of CZK 4.3 million (approx. USD 215,000)
• The team: 2 senior MBI engineers, 34 specialised AI agents, and 1 Product Owner from our team
• Built from the ground up — not translated line by line from old code

---

Why we took this on

We have been running AffilBox since 2009. Over fifteen years it has grown into a platform that powers affiliate programmes, partner management, campaigns, tracking and all the operations around them for a significant number of e-commerce businesses.

Over those fifteen years it also accumulated many compounding issues that long and established software generally tends to over time.

Every new feature went into a codebase that already carried years of decisions made in a different era and a different context. Eventually it showed up everywhere:

• Changes to the code became slower and riskier.
• New features took far longer than they should have.
• Automated tests covered only part of the system, so every change was harder to validate and the risk of regressions kept growing.
• Technical and product documentation never kept pace with how the platform evolved.
• Security work became progressively harder to address within the original architecture, and almost impossible to address systematically.
• Deployments and database migrations relied on manual steps — a lot of effort and unnecessary risk on every release.
• We could not see into the running system the way we needed to. Proper monitoring, centralised logging and insight into performance and load were missing.
• The infrastructure cost us more financially and required more attention than it needed to.

So this was never simply a case of an ageing technology stack. The real problem was everything that had built up around it — delivery risk, operational risk and, ultimately, business risk.

“Deciding to replace a platform that has worked for fifteen years and pays the bills is not an easy call. But we reached the point where every year of delay meant paying more for the same thing. The question stopped being whether to rebuild and became when.”

Ondrej Martinek, CEO, AffilBox

The risk nobody says out loud

What weighed on us most was not the code. It was where the knowledge about it lived.

A substantial part of the technical understanding of the platform sat in the head of one senior developer. Not just the code — also years of unspoken architectural decisions, edge cases, dependencies and the historical reasons why the product behaves the way it does in specific situations.

We knew about it. And we knew what it meant: if that knowledge ever became unavailable, a business-critical platform would be significantly harder to maintain, let alone evolve.

The new platform therefore had to solve two problems at once:

1. Replace the original technology.
2. Move the knowledge out of one person’s head into architecture, code and documentation that anyone could pick up.

Development that was slow and expensive

The old architecture was also making our future more expensive.

Before a developer could add a feature, they first had to understand the accumulated complexity around it and then work around it. Product development was slower and costlier than the actual scope of the work warranted.

For a SaaS company this is a direct commercial constraint. Every additional month a feature needs is a month it is not generating revenue, not improving retention, not reducing support load and not answering the competition.

What we needed was not a technical migration. It was a foundation we could build on quickly.

The conventional route: 14 months and CZK 4.3 million

We had a classic rebuild estimated. The answer came back:

14+ months of development and approximately CZK 4.3 million (around USD 215,000).

That set up an unattractive choice. Either keep investing in a platform that was getting harder to work with, or commit more than a year and significant capital to a traditional rewrite — while running both worlds side by side the entire time.

MBI proposed a third option: instead of redesigning the brief, redesign the way software gets delivered.

Why we went a different way

Rather than assembling a larger development team, MBI applied an AI-native delivery model.

The project was delivered by roughly two full-time equivalents of senior people:

• ~0.5 FTE MBI software architect
• ~1.5 FTE MBI developers
• 1 Product Owner from our side

That team was supported by 34 specialised AI agents.

What matters is how they were used. This was not a smarter autocomplete in an editor. AI was embedded across the entire delivery lifecycle — from analysis and requirements through architecture, development, review, testing and documentation to deployment and release. People kept ownership of architecture, product decisions, engineering quality and outcomes. The agents supplied execution capacity.

That let a small senior team orchestrate substantially more parallel work than its headcount would suggest.

“We did not want to translate the old application line by line into a new technology. That would have carried over every decision that made the platform hard to maintain in the first place. We used the old code as the source of truth for what the product has to do — not as a blueprint for how it should be built.”

Petr Volf, Software Architect, MBI

How it actually worked

1. Reading fifteen years

The original codebase was not just software. It was the most complete documentation of our product that existed — it simply had never been written down.

AI agents went through it systematically and extracted the existing functionality, business rules, dependencies, data flows, integration points, legacy behaviour and architectural constraints.

The goal was never translation. The goal was to know exactly what the new product had to do.

2. From requirements to architecture

Existing functionality, business requirements and input from our Product Owner were turned into structured requirements and implementation scopes.

That created an explicit chain:

business requirement → specification → architecture → implementation → validation

The Product Owner stayed responsible for product decisions. AI accelerated the preparation and refinement of the specifications.

MBI designed the architecture from scratch, aiming for a result that would be easier to understand, cheaper to operate, easier to extend, less dependent on specific individuals and better suited to further AI-assisted development. Application architecture and infrastructure were designed together.

3. Agentic development — with the review that keeps it honest

The implementation itself ran through coordinated AI workflows. Different agents worked on defined parts while the human team held architecture, dependencies, standards, integration, priorities and product behaviour.

Generated code was never assumed to be finished. Review and refactoring were built into the process, because this is where the main risk of AI-assisted development sits: producing software fast and producing a new generation of technical debt along with it. Code was continuously measured against the target architecture and maintainability requirements.

“Writing code faster is worth only so much when requirements, architecture, testing and releases are the bottleneck. It starts to pay off when AI covers the whole path from requirement to deployed software — and when architectural control still sits above it. Without that, you are just building your next problem faster.”

Lukas Moravec, Delivery Lead, MBI

4. Testing and documentation as part of development, not cleanup after it

Testing ran continuously rather than at the end. AI supported both the creation and the execution of validation workflows over new functionality — which mattered a great deal, because the new application had to reproduce the capabilities of a platform that had been evolving for fifteen years.

Documentation was produced alongside the code. Precisely so that the knowledge would never again sit in one person’s head. Architecture, functionality and implementation context became explicit artifacts — readable by future developers and by AI systems alike.

5. Operations, CI/CD and visibility into the system

The change went well beyond application code. Deployment, infrastructure, CI/CD, the database migration process, monitoring and logging were all redesigned.

Manual releases were replaced by a dependable deployment foundation, and we can finally see into the running system. AI also supported the coordination of moving functionality from done through validation to release.

Where Claude fits in

The whole delivery model runs on Anthropic’s Claude models. MBI used them in three modes:

• Claude for Team (claude.ai) — analysing the fifteen-year-old codebase, reconstructing business rules, preparing requirements and specifications, and product documentation.
• Claude Code — agentic development directly against the repository: implementation, code review, refactoring and tests.
• Claude API — orchestrating the 34 specialised agents across delivery phases, each with its own role and its own brief.

That combination is what separates this from “a developer with an AI assistant”. AI was not a tool inside a single step. It was continuous capacity across the whole process.

What we got out of it

Four months instead of fourteen.

We had the complete replacement in 4 months against a conventional estimate of at least 14. That is more than a 3x improvement in delivery speed and 10+ months saved. Ten months in which we can use the new foundation for customer improvements, new features, commercial opportunities and retiring support for the old system.

Roughly 80% lower development cost.

Against the CZK 4.3 million estimate. The saving did not come from cutting corners on quality, but from changing the relationship between engineering output and headcount. Instead of a large conventional team, a small group of experienced engineers brought their capacity in the form of agents.

A complete rebuild, not a prototype.

This was not a pilot, a selected module or a proof of concept. The entire platform was rebuilt, including all the functionality required to replace the original application.

The end of single-person dependency.

The new application rests on clean architecture, explicit specifications, maintainable code, automated tests, documentation and standardised delivery practices. The knowledge moved out of one head and into the system.

Cheaper and clearer operations.

The new architecture has simpler, more efficient infrastructure requirements. Deployment, migrations, monitoring and logging are modernised — lower operational burden and, at last, real visibility into what the system is doing.

Faster development from here on.

This may be the most important part for us. We did not just get the same product sooner. We got a different foundation. New features no longer go into a fifteen-year-old architecture, but into code designed to be changed.

What this means for our customers

For the e-shops and companies running affiliate programmes through AffilBox, this change will not show up as “a new version”. It will show up in what you can expect next.

Features we used to postpone because of how hard they would have been to fit into the old architecture are now realistic. Shipping changes is safer, so we are not afraid to ship more of them. And because we can see into the system, we spot misbehaviour earlier.

The platform your affiliate programme runs on is also the platform we can now develop substantially faster.

“Being the only product person against thirty-four agents sounds terrifying, but what it actually meant was that I spent my time making product decisions instead of waiting for development capacity. The speed at which a specification turned into a working feature I could try was something we had not experienced in fifteen years.”

Ondrej Martinek, CEO, AffilBox

---

About the project

• Client: AffilBox – a Czech SaaS platform for affiliate programme management, on the market since 2009
• Delivery partner: MBI
• Scope: complete replacement of the original platform
• Duration: 4 months
• Team: ~0.5 FTE MBI software architect, ~1.5 FTE MBI developers, 34 AI agents, 1 AffilBox Product Owner
• Technology used: Claude Code, Claude API and Claude for Team (Anthropic)