Naši 15 let starou platformu jsme přepsali za čtyři měsíce (případová studie)

Místo čtrnácti měsíců a 4,3 milionu korun. Takhle proběhl kompletní rebuild AffilBoxu, na kterém jsme pracovali v posledních měsících. A kolem tohoto projektu jsme připravili i tuto případovou studii.

Ve zkratce

• Kompletní náhrada SaaS platformy, která běžela a rostla 15 let
• 4 měsíce místo odhadovaných 14+
• Přibližně o 80 % nižší náklady na vývoj oproti konvenčnímu odhadu 4,3 milionu Kč (cca 215 000 USD)
• Tým: 2 FTE seniorních inženýrů MBI, 34 specializovaných AI agentů a 1 náš Product Owner
• Postavené od základu – ne přepsané jedna ku jedné podle starého kódu

Proč jsme to vůbec řešili

AffilBox provozujeme od roku 2009. Za těch patnáct let se z něj stala platforma, na které běží affiliate programy, správa partnerů, kampaně, tracking a celý provoz kolem toho pro řadu e-shopů.

A za těch patnáct let se v ní taky nastřádalo všechno, co se v dlouho žijícím softwaru nastřádat dá.

Každá nová funkce se přidávala do kódu, který už nesl roky rozhodnutí uč iněných v jiné době a v jiném kontextu. Postupně se to začalo projevovat všude:

Úpravy kódu byly čím dál pomalejší a rizikovější.

Nové funkce trvaly nesrovnatelně déle, než by měly.

Automatizované testy pokrývaly jen část systému, takže každá změna se ověřovala hůř a riziko regrese rostlo.

Technická a produktová dokumentace nestíhala tempo, jakým se platforma měnila.

Bezpečnostní témata se v původní architektuře řešila čím dál obtížněji.

Nasazování a databázové migrace stály na manuálních krocích – hodně práce a zbytečné riziko u každého releasu. Do běžícího systému jsme neviděli tak, jak bychom potřebovali. Chybělo pořádné monitorování, centrální logování a přehled o výkonu a zátěži.

Infrastruktura nás stála víc peněz a víc starostí, než by při dnešních možnostech musela.

Nešlo tedy o to, že za ta léta nabalilo bychom měli „starý technologický stack“. Problém – provozní riziko, riziko při vývoji a nakonec i riziko byl v tom, co se kolem nějbyznysové.

„Rozhodnutí nahradit platformu, která patnáct let funguje a živí firmu, není snadné. Ale došli jsme do bodu, kdy každý další rok odkládání znamenal vyšší cenu za totéž. Nebavili jsme se o tom, jestli přepsat, ale kdy.“

Ondřej Martinek, majitel AffilBoxu

Riziko, o kterém se nemluví nahlas

Nejvíc nás ale netížil kód. Tížilo nás, kde byla uložená znalost o něm.

Zásadní část technického porozumění platformě měl v hlavě jeden seniorní vývojář. Nejen kód – taky roky nevyslovených architektonických rozhodnutí, okrajové případy, závislosti a historické důvody, proč se produkt v konkrétních situacích chová právě takhle.

Věděli jsme o tom. A věděli jsme taky, co to znamená, neboli kdyby tahle znalost přestala být k dispozici, byznysově kritickou platformu by bylo výrazně těžší udržovat, natož rozvíjet.

Nová platforma tedy musela vyřešit dvě věci najednou:

1. Nahradit původní technologii.
2. Převést znalost z hlavy jednoho člověka do architektury, kódu a dokumentace, kterým rozumí kdokoli další.

Vývoj, který byl pomalý a drahý

Stará architektura nám zároveň zdražovala budoucnost. Aby vývojář mohl přidat funkci, musel nejdřív pochopit nahromaděnou složitost okolo a pak ji obejít. Rozvoj produktu tím byl pomalejší a dražší, než by odpovídalo tomu, co se reálně přidávalo.

U SaaS firmy je tohle přímé obchodní omezení. Každý měsíc navíc, který funkce potřebuje k dodání, je měsíc, kdy nevydělává, nezlepšuje retenci, nesnižuje zátěž podpory a nereaguje na konkurenci. Nepotřebovali jsme tedy technickou migraci. Potřebovali jsme základ, na kterém se dá stavět rychle.

Konvenční cesta: 14 měsíců a 4,3 milionu

Klasický re build jsme si nechali nacenit. Odhad zněl:

14+ měsíců vývoje a přibližně 4,3 milionu Kč (zhruba 215 000 USD).

To postavilo nepříjemnou volbu. Buď dál investovat do platformy, se kterou se pracuje čím dál hůř, nebo dát víc než rok času a významný kapitál do tradičního přepisu – a celou tu dobu provozovat oba světy vedle sebe.

MBI přišlo se třetí možností: nepředělávat zadání, ale samotný způsob, jakým se software dodává.

Proč jsme šli jinudy

Místo většího vývojářského týmu nasadilo MBI AI-native delivery model.

Projekt dodávaly zhruba dva full-time ekvivalenty seniorních lidí:

• ~0,5 FTE softwarový architekt MBI
• ~1,5 FTE vývojáři MBI
• 1 Product Owner z naší strany

Tenhle tým doplňovalo 34 specializovaných AI agentů.

Podstatné je, jak byli použití. Nešlo o chytřejší našeptávač v editoru. AI byla zapojená napříč celým životním cyklem dodávky – od analýzy a požadavků přes architekturu, vývoj, review, testování a dokumentaci až po nasazení a release. Lidé si nechali odpovědnost za architekturu, produktová rozhodnutí, kvalitu a výsledek. Agenti dodali výkon.

Díky tomu zvládl malý seniorní tým řídit podstatně víc paralelní práce, než by odpovídalo počtu lidí.

„Nechtěli jsme starou aplikaci přeložit řádek po řádku do nové technologie. To by znamenalo přenést i všechna rozhodnutí, kvůli kterým se ta platforma stala těžko udržovatelnou. Starý kód jsme použili jako zdroj pravdy o tom, co produkt musí umět – ne jako předlohu, jak to má být postavené.“

Petr Volf, Software Architect, MBI

Jak to probíhalo

1. Přečíst patnáct let

Původní kódová základna nebyla jen software. Byla to nejúplnější existující dokumentace našeho produktu – jen nepsaná. AI agenti ji systematicky prošli a vytáhli z ní existující funkcionalitu, byznysová pravidla, závislosti, datové toky, integrační body, historické chování a architektonická omezení.

Cílem nebyl překlad. Cílem bylo vědět, co nový produkt musí umět.

2. Od požadavků k architektuře

Existující funkcionalita, byznysové požadavky a vstupy našeho Product Ownera se převedly do strukturovaných požadavků a implementačních zadání.

Vznikl tím explicitní řetězec:

byznysový požadavek → specifikace → architektura → implementace → validace

Product Owner zůstal odpovědný za produktová rozhodnutí. AI zrychlila přípravu a zpřesňování specifikací.

Architekturu MBI navrhlo znovu – s cílem, aby výsledek byl srozumitelnější, levnější na provoz,snáz rozšiřitelný, méně závislý na konkrétních lidech a připravený na další AI-asistovaný vývoj. V rámci infrastruktury pokračujeme ve spolupráci s naším letitým osvědčeným partnerem Stable / Webglobe.

Aplikační architektura a infrastruktura se navrhovaly společně.

3. Agentní vývoj a review, které ho drží na uzdě

Samotná implementace běžela v koordinovaných AI workflow. Různí agenti pracovali na vymezených částech, zatímco lidský tým držel architekturu, závislosti, standardy, integraci, priority a chování produktu.

Vygenerovaný kód se automaticky nepovažoval za hotový. Do procesu bylo zabudované review a refaktoring, protože tady číhá hlavní riziko AI vývoje. Tím je vyrobit software rychle a spolu s ním novou generaci technického dluhu. Kód se průběžně poměřoval proti cílové architektuře a nárokům na udržovatelnost.

„Psát kód rychleji má omezenou cenu, když jsou úzkým hrdlem požadavky, architektura, testování a releasy. Smysl to dává až ve chvíli, kdy AI pokryje celou cestu od požadavku k nasazenému softwaru. A kdy nad tím pořád stojí architektonická kontrola. Bez ní si jen rychleji vyrobíte pro blém, který jste zrovna odcházeli řešit.“

Lukáš Moravec, Delivery Lead, MBI

4. Testování a dokumentace jako součást vývoje, ne úklid po něm

Testování běželo průběžně, ne až na konci. AI podporovala tvorbu i běh validačních workflow nad novou funkcionalitou. Což bylo zásadní, protože nová aplikace musela zreprodukovat schopnosti platformy, která se vyvíjela patnáct let.

Dokumentace vznikala spolu s kódem. Přesně kvůli tomu, aby znalost už nikdy neseděla jen v hlavě jednoho člověka. Architektura, funkcionalita a implementační kontext se staly explicitními pro další vývojáře i pro AI.

5. Provoz, CI/CD a viditelnost do systému

Změna se netýkala jen aplikačního kódu. Znovu se navrhlo nasazování, infrastruktura, CI/CD, proces databázových migrací, monitoring i logování. Manuální releasy nahradil spolehlivý deployment a do běžícího systému konečně vidíme. AI pomáhala i s koordinací cesty od hotové funkce přes validaci až k releasu.

Kde v tom byl Claude

Celý delivery model stojí na modelech Claude od Anthropicu. MBI je používalo ve 3 režimech:

• Claude for Team (claude.ai) – analýza patnáctileté kódové základny, rekonstrukce byznysových pravidel, příprava požadavků a specifikací, produktová dokumentace.
• Claude Code – agentní vývoj přímo nad repozitářem: implementace, code review, refaktoring a testy.
• Claude API – orchestrace 34 specializovaných agentů napříč fázemi dodávky, každý s vlastní rolí a vlastním zadáním.

Právě tahle kombinace odlišuje výsledek od „vývojáře s AI asistentem“. AI nebyla nástroj uvnitřjednoho kroku. Byla průběžnou kapacitou napříč celým procesem.

Co nám to přineslo

Čtyři měsíce místo čtrnácti.

Kompletní náhradu jsme měli za 4 měsíce proti konvenčnímu odhadu minimálně 14 měsíců. To jevíc než trojnásobné zrychlení a 10+ měsíců uspořeného času. Deset měsíců, během kterýchmůžeme nový základ používat pro zlepšení pro zákazníky, nové funkce, obchodní příležitosti aodstavení podpory starého systému.

Přibližně o 80 % nižší náklady na vývoj.

Proti odhadu 4,3 milionu Kč. Úspora nevznikla tím, že by se šetřilo na kvalitě, ale tím, že se změnil vztah mezi objemem odvedené práce a počtem lidí. Místo velkého konvenčního týmu malá skupina zkušených inženýrů, která si výkon přinesla v podobě agentů.

Kompletní rebuild, ne prototyp.

Ne byl to pilot, vybraný modul ani proof of concept. Přepsala se celá platforma, včetně funkcionality nutné k nahrazení původní aplikace.

Konec závislosti na jednom člověku.

Nová aplikace stojí na čisté architektuře, explicitních specifikacích, udržovatelném kódu, automatizovaných testech, dokumentaci a standardizovaných postupech. Znalost se přesunula z hlavy do systému.

Levnější a přehlednější provoz.

Nová architektura má jednodušší a efektivnější nároky na infrastrukturu. Nasazování, migrace, monitoring i logování jsou modernizované – nižší provozní zátěž a konečně přehled o tom, cose v systému děje.

Rychlejší vývoj dobudoucna.

Tohle je pro nás možná nejdůležitější. Nedostali jsme jen stejný produkt dřív. Dostali jsme jiný základ. Nové funkce už nepřidáváme do patnáctileté architektury, ale do kódu navrženého pro to, aby se měnil.

Co to znamená pro naše zákazníky

Pro e-shopy a firmy, které přes AffilBox provozují affiliate programy, se tahle změna neprojeví jako „nová verze“. Projeví se v tom, co se dá čekat dál. Funkce, které jsme dřív odkládali kvůli tomu, jak náročné by bylo je zasadit do staré architektury, jsou teď reálné. Nasazování změn je bezpečnější, takže se jich nebojíme dělat víc.

A protože do systému vidíme, umíme dřív poznat, když se něco nechová, jak má. Platforma, na které vám běží affiliate program, je zároveň platforma, kterou teď umíme rozvíjet podstatně rychleji.

„Být jediný produktový člověk proti třiceti čtyřem agentům zní děsivě, ale ve výsledku to znamenalo, že jsem trávil čas rozhodováním o produktu místo čekáním na kapacitu vývoje. Rychlost, jakou se ze specifikace stala hotová funkce k vyzkoušení, byla něco, co jsme za patnáct let nezažili.“

Ondřej Martinek, CEO, AffilBox

O projektu

• Zadavatel: AffilBox – česká SaaS platforma pro správu affiliate programů, na trhu od roku 2009
• Dodavatel: MBI
• Rozsah: kompletní náhrada původní platformy
• Délka: 4 měsíce
• Tým: ~0,5 FTE softwarový architekt MBI, ~1,5 FTE vývojáři MBI, 34 AI agentů, 1 Product Owner
• Použité technologie: Claude Code, Claude API a Claude for Team (Anthropic)