Dług technologiczny — spłacać czy ogłosić bankructwo?

Tech debt jest jak hipoteka: w małych dawkach do udźwignięcia, śmiertelna gdy ignorujesz odsetki. Większość firm nie zna nawet miesięcznej raty. Nie mają bilansu technicznego, nie liczą odsetek, nie planują spłaty. Dowiadują się o skali w piątek o 17:00, gdy system pada i nikt nie umie go podnieść.

W Do More Soft prowadzimy rescue missions od pięciu lat — ratujemy projekty, które inni porzucili. Widzieliśmy każdy poziom długu, od kosmetycznego po terminalny. Poniżej framework, który mówi wprost: ratować czy przepisać od zera w 8 tygodni.

5 poziomów długu technologicznego

Każdy poziom ma operacyjną konsekwencję — nie teoretyczną, mierzalną w sprintach.

1. Kosmetyczny — niespójne nazewnictwo, brak komentarzy. 10-20% wolniej, ale bez prod fires.
2. Strukturalny — brak separacji warstw, brak testów. Feature trwa 3× dłużej, regresja co sprint.
3. Architektoniczny — monolit bez API, baza jako integration point. Każda integracja to projekt na kwartał.
4. Infrastrukturalny — zero CI/CD, deploy ręczny przez FTP. Piątkowy deploy = rosyjska ruletka.
5. Terminalny — martwa technologia, zerowe testy, oryginalny zespół odszedł. 80% budżetu IT na utrzymanie, rozwój praktycznie zamrożony.

Poziom 1: Kosmetyczny

Nieoptymalne zapytania SQL, duplikacja, brak komentarzy. System działa poprawnie, jest nieprzyjemny w utrzymaniu. Naprawa: refaktor w ramach normalnych sprintów, bez dedykowanego budżetu. Każdy projekt ma ten poziom i to jest OK.

Poziom 2: Strukturalny

UI pomieszane z logiką biznesową, brak testów, hardcoded config. System działa, ale każda zmiana wymaga modyfikacji w 5 miejscach i generuje regresję. Naprawa: dedykowany sprint refaktoryzacyjny co 4-6 tygodni.

Poziom 3: Architektoniczny

Monolit, który nie skaluje. Baza jako integration point — systemy komunikują się przez shared database. Zero API, zero integracji. Nowe funkcjonalności trwają 3-5× dłużej. Naprawa: wydzielenie krytycznych modułów do osobnych serwisów, warstwa API. 2-4 miesiące pracy.

Poziom 4: Infrastrukturalny

Brak CI/CD, deploy przez FTP, produkcja na jednym serwerze bez backupu, zero monitoringu. System działa na zasadzie “niech nikt tego nie dotyka”. Ryzyko catastrophic failure plus całkowita zależność od jednej osoby, która “wie, jak to działa”. Naprawa: budowa infrastruktury od zera przy żywym systemie — wymiana silnika w jadącym samochodzie. 1-3 miesiące.

Poziom 5: Terminalny

Classic ASP, AngularJS, PHP 5. Zero testów, zero dokumentacji, oryginalny zespół odszedł. Każda zmiana generuje nieprzewidywalne efekty uboczne. Nikt nie rozumie systemu w całości. Utrzymanie pochłania 80%+ budżetu IT. Decyzja binarna: ratować czy przepisać.

Rescue Assessment Matrix — kiedy ratować vs rewrite

Przeszliśmy 30+ razy. Trzy z pięciu wymiarów 3+? Do uratowania. Trzy 1-2? Rewrite wygrywa. Kiedy przychodzi klient z projektem “do ratowania”, robimy 3-5 dniowy audyt technologiczny i oceniamy 5 wymiarów na skali 1-5 (1 = do wyrzucenia, 5 = solidne): jakość bazy danych, pokrycie testami, design API, infrastruktura, dokumentacja.

Reguła decyzyjna

Trzy z pięciu wymiarów na 3+ — rescue mission. Ratujemy to, co dobre, przepisujemy to, co złe. Typowy koszt: 40-60% budżetu pełnego rewrite, czas: 2-4 miesiące. Trzy wymiary na 1-2 — rewrite od zera. Ratowanie kosztowałoby więcej niż nowy system i dałoby gorszy wynik. Baza danych jest punktem dźwigni: jeśli dane są dobrze zaprojektowane, reszta jest odtwarzalna.

W projekcie automotive: baza solidna (5/5), API legacy (1/5), testy zerowe (1/5). Uratowane, bo 2 z 5 do uratowania — baza i frontend. API i testy napisaliśmy od zera w 14 tygodni, klient zachował dane i procesy.

Realne TCO ignorowania długu

Firmy, które ignorują dług, płacą odsetki w każdym wymiarze TCO: wolniejszy time-to-market (konkurencja wyprzedza), 90% budżetu IT na utrzymanie zamiast rozwoju, uzależnienie od kluczowych osób (odejście jednego programisty paraliżuje projekt), ryzyko catastrophic failure.

Najdroższa pozycja w TCO długu to koszt utraconych szans. Firma, która mogłaby wprowadzić produkt w 3 miesiące, wprowadza go w 12 — bo 75% capacity zespołu pochłania walka z długiem. W tym czasie konkurencja zajmuje rynek. Ten koszt jest niewidzialny w bilansie i bolesny w wynikach kwartalnych.

Playbook ratunkowy: rescue mission krok po kroku

Tydzień 1: Audyt i stabilizacja. Krytyczne luki bezpieczeństwa, monitoring, backup, dokumentacja architektury as-is.

Tydzień 2-4: Refaktoryzacja priorytetów. Wydzielamy core logic od UI, testy do krytycznych ścieżek, CI/CD pipeline.

Miesiąc 2-3: Modernizacja. Nowe API, migracja infrastruktury, eliminacja martwego kodu.

Miesiąc 4+: Rozwój. Nowe funkcjonalności na solidnym fundamencie.

Reguła 20%

Piątkowy sprint w DailyHair: 2h refactor, 1h docs, 30min test coverage. Nie opcjonalnie. To wzorzec, który egzekwujemy u każdego klienta z kulturą inżynierską.

Dlaczego działa — efekt kumulatywny

20% capacity każdego sprintu na spłatę długu. 20% dziś oszczędza 200% za rok, bo każdy nieusunięty skrót blokuje kolejne decyzje architektoniczne. Zespół, który regularnie spłaca dług, jest szybszy i pisze lepszy kod. Klient płaci za to dwa razy: raz w niższym koszcie utrzymania, drugi raz w wyższym tempie ficzerów.

Jak egzekwować — spike card, non-negotiable backlog

Spike card “Tech Debt 20%” w backlogu każdego sprintu, prioritetyzowana razem z ficzerami, nie po nich. Definition of Done identyczne jak dla story biznesowego. Brak spike → sprint nie rusza. Dla firm bez kultury technicznej: jeden piątek w miesiącu wyłącznie na cleanup (“Tech Debt Fridays”). To inwestycja w przyszłą produktywność, nie strata.

Robimy to sami

Q2 2026, velocity 45 SP. 9 punktów na piątkowy tech debt, 36 na ficzery. Przy każdym nowym projekcie pokazujemy klientowi licznik długu z poprzedniego systemu — to zwykle kończy dyskusję, czy 20% jest “na pewno potrzebne”.

FAQ

Co to dług technologiczny i jak go mierzyć? Procent budżetu IT na utrzymanie zamiast rozwoju. Powyżej 70% → czerwona flaga.

Kiedy refaktor a kiedy rewrite? Rescue Matrix, 5 wymiarów × skala 1-5. Trzy na 3+ → rescue (40-60% kosztu rewrite). Trzy na 1-2 → rewrite.

Co to reguła 20%? 20% capacity sprintu na spłatę długu, spike card w backlogu, nie “jeśli starczy czasu”.

Ile kosztuje firmę dług technologiczny? 60-90% budżetu IT na utrzymanie. Najdroższa pozycja to koszt utraconych szans.