Jak ocenić dług technologiczny przed przejęciem

W większości transakcji dług technologiczny nie jest ukrywany. On po prostu nie zostaje policzony. Zespół zarządzający mówi o nim ogólnie, jako o czymś, czym trzeba się będzie kiedyś zająć, dokumenty w data roomie milczą, a fundusz podpisuje umowę z założeniem, że skoro produkt działa i klienci płacą, technologia jakoś udźwignie plan wzrostu. Rachunek przychodzi później, zwykle w pierwszym roku po zamknięciu transakcji, gdy okazuje się, że każda nowa funkcja kosztuje dwa razy więcej, niż zakładał model, a połowa budżetu na rozwój produktu idzie na łatanie tego, co odziedziczono.

Dług technologiczny jest jednym z niewielu ryzyk, które da się zmierzyć przed podpisaniem umowy, a mimo to bywa pomijany. Tylko około 15 procent transakcji private equity obejmuje dedykowane techniczne due diligence, co oznacza, że w większości przypadków rdzeń biznesu przyjmowany jest na słowo. Poniżej praktyczne ujęcie tego, jak ocenić dług technologiczny przed przejęciem: czym on właściwie jest z perspektywy inwestora, gdzie go szukać, jak zamienić obserwacje inżynierskie w liczbę, która trafi do modelu, i jak wygląda badanie poprowadzone w sposób nadający się do przedstawienia komitetowi inwestycyjnemu.

Czym jest dług technologiczny z perspektywy inwestora

W rozmowach inżynierskich dług technologiczny bywa sprowadzany do jakości kodu. Dla inwestora to definicja zbyt wąska i myląca. Z perspektywy transakcji dług technologiczny to różnica między tym, jak system jest zbudowany dzisiaj, a tym, jak musiałby być zbudowany, żeby udźwignąć tezę inwestycyjną. Jeśli plan zakłada podwojenie liczby klientów, wejście na trzy nowe rynki i integracje z partnerami, to długiem jest wszystko, co temu planowi stoi na drodze: architektura, która nie pozwala skalować się poziomo, brak granic między modułami utrudniający budowanie API, procesy wydawnicze spowalniające dostarczanie, luki bezpieczeństwa zamykające drogę do klientów korporacyjnych.

Z tego wynika ważna konsekwencja. Ta sama baza kodu może być obciążona długiem przy jednej tezie inwestycyjnej i całkowicie wystarczająca przy innej. System, który przez dekadę stabilnie obsługuje setki tysięcy transakcji rocznie, jest sprawdzonym aktywem, jeśli plan zakłada spokojny wzrost organiczny, a poważnym ograniczeniem, jeśli plan zakłada agresywną ekspansję i szybkie wypuszczanie nowych funkcji. Dlatego ocena długu oderwana od tezy inwestycyjnej jest ćwiczeniem akademickim. Sens ma dopiero pytanie: czego ten konkretny plan wymaga od technologii i ile kosztuje domknięcie luki.

Warto też oddzielić dług od zaniedbania. Każdy system, który działa wystarczająco długo, żeby zbudować wartość, gromadzi dług, i sam ten fakt nie jest sygnałem ostrzegawczym. Sygnałem jest brak świadomości: gdy zespół nie potrafi powiedzieć, gdzie ten dług leży, ile kosztuje i co się stanie, jeśli nic z nim nie zrobić.

Dlaczego dług trzeba policzyć przed podpisaniem

Kolejność ma tu znaczenie finansowe. Dług zidentyfikowany przed podpisaniem umowy staje się elementem negocjacji: obniżką ceny, korektą mnożnika, zapisem w umowie albo pozycją w planie tworzenia wartości, którą fundusz świadomie finansuje. Ten sam dług odkryty pół roku po zamknięciu transakcji jest już tylko kosztem, którego nikt nie zaplanował, obciążającym budżet rozwoju produktu i opóźniającym realizację tezy.

Jest jeszcze drugi, mniej oczywisty powód. Wycena długu przed transakcją zmienia sposób planowania pierwszych stu dni. Fundusz, który wchodzi w spółkę z gotową listą priorytetów naprawczych i oszacowanym nakładem, zaczyna tworzyć wartość od pierwszego dnia. Fundusz, który zaczyna od odkrywania, traci pierwszy kwartał na diagnozę, a często i drugi na przekonywanie zespołu, że diagnoza jest trafna. Różnica bywa warta więcej niż samo badanie.

Osiem obszarów, w których szuka się długu

Rzetelna ocena długu technologicznego nie polega na przejrzeniu kodu i wystawieniu oceny. Polega na systematycznym przejściu przez obszary, w których dług realnie wpływa na zdolność spółki do realizacji planu. W badaniach prowadzonych przez Altimi jest ich osiem i każdy z nich odpowiada na inne pytanie inwestora.

• Architektura i stos technologiczny. Analiza zależności, mapa długu i weryfikacja ścieżek aktualizacji. To tutaj wychodzą komponenty po zakończeniu wsparcia producenta oraz miejsca, w których moduły są ze sobą tak splecione, że każda zmiana dotyka połowy systemu.
• Jakość kodu i praktyki inżynierskie. Analiza statyczna, pokrycie testami, dojrzałość procesu CI/CD i ocena kondycji kodu na tle standardów rynkowych. Odpowiada na pytanie, czy zespół może bezpiecznie zmieniać system, czy każda zmiana jest ryzykiem.
• Infrastruktura i gotowość chmurowa. Architektura wdrożeń, efektywność kosztowa, pułap skalowalności i uzależnienie od dostawcy. Tutaj widać, czy koszt utrzymania będzie rósł liniowo, czy szybciej niż przychody.
• Bezpieczeństwo i zgodność. Przegląd ryzyk według OWASP, wzorce uwierzytelniania, sposób przetwarzania danych i ekspozycja regulacyjna, w tym RODO, SOC 2 i ISO 27001. Luki w tym obszarze potrafią zamknąć całe segmenty rynku.
• Dojrzałość AI i danych. Ocena wykorzystania sztucznej inteligencji, gotowość potoków danych, ład nad modelami i realne możliwości tworzenia wartości. Coraz częściej to właśnie ten obszar decyduje, czy spółka będzie kumulować przewagę, czy zostanie w tyle.
• Skalowalność i scenariusze wzrostu. Wyniki testów obciążeniowych, wykonalność skalowania poziomego i prognozy kosztów przy wzroście dwukrotnym, pięciokrotnym i dziesięciokrotnym. To najbardziej bezpośrednie zderzenie technologii z tezą inwestycyjną.
• Dojrzałość zespołu i dostarczania. Struktura organizacji inżynierskiej, tempo dostarczania, ryzyko kluczowych osób i ocena planu rekrutacyjnego. Dług potrafi siedzieć nie w kodzie, lecz w tym, że tylko jedna osoba wie, jak działa rozliczanie płatności.
• Roadmapa tworzenia wartości na 90 dni. Plan naprawczy z oszacowaniem nakładu, szybkimi zwycięstwami i inwestycjami strategicznymi po zamknięciu transakcji. To moment, w którym diagnoza zamienia się w plan działania.

Przejście przez wszystkie osiem obszarów ma jeszcze jedną zaletę. Dług rzadko występuje pojedynczo. Słabe pokrycie testami, niedojrzały proces wydawniczy i skoncentrowana wiedza w jednej osobie zwykle chodzą parami, bo mają wspólną przyczynę: presję na dostarczanie kosztem fundamentów. Ocena obszar po obszarze pokazuje ten wzorzec, a nie tylko pojedyncze objawy.

Jak zamienić obserwacje inżynierskie w liczbę

Najsłabszym punktem większości technicznych ocen jest to, że kończą się na opisie. Raport stwierdza, że architektura jest ciasno powiązana, a pokrycie testami niskie, i zostawia inwestora z pytaniem, co z tego wynika dla ceny. Ocena użyteczna w transakcji musi przejść trzy kroki dalej.

Pierwszy krok to oszacowanie nakładu. Każde istotne ustalenie powinno mieć przypisany szacunek pracy potrzebnej do jego usunięcia, wyrażony w konkretnych zasobach i czasie. Bez tego nie da się nic wpisać do modelu.

Drugi krok to priorytetyzacja według istotności. Nie każdy dług trzeba spłacać. Część można świadomie zostawić, jeśli nie koliduje z tezą inwestycyjną. Dlatego ustalenia porządkuje się w macierzy ryzyka według wagi i pilności, oddzielając to, co musi zostać naprawione przed skalowaniem, od tego, co można monitorować.

Trzeci krok to przełożenie na język transakcji. Skwantyfikowany dług wchodzi do modelu na trzy sposoby: jako jednorazowy koszt naprawy w planie tworzenia wartości, jako podwyższony koszt utrzymania w prognozie i jako ryzyko opóźnienia realizacji tezy, które przekłada się na mnożnik. Dopiero w tej postaci ocena techniczna staje się argumentem w negocjacji, a nie załącznikiem, którego nikt nie czyta.

Pomocna jest tu spójna skala oceny. Format czerwony, bursztynowy, zielony, przypisany do każdego obszaru wraz z punktacją, pozwala partnerowi i dyrektorowi inwestycyjnemu zobaczyć obraz całości w kilkanaście sekund, a dyrektorowi technicznemu zejść do szczegółu tam, gdzie to potrzebne. Ta sama informacja obsługuje dwie bardzo różne potrzeby.

Sygnały, których nie widać w data roomie

Doświadczenie z ponad stu badań po stronie kupującego pokazuje, że najkosztowniejsze ustalenia rzadko wynikają z dokumentów. Ujawniają się dopiero przy dostępie do kodu i w rozmowach z zespołem inżynierskim.

W jednym z badanych podmiotów, dojrzałym marketplace B2B działającym w Europie od ponad dekady, wskaźniki komercyjne były bez zarzutu, a platforma udowodniła swoją odporność latami działania. Dopiero analiza architektury pokazała, że organiczny wzrost wytworzył ciasne zależności między modułami i ograniczone granice API. Nic nadzwyczajnego dla platformy na tym etapie, ale konsekwencja jest konkretna: tempo dostarczania spada wraz ze wzrostem zespołu, a kolejne integracje zewnętrzne stają się coraz trudniejsze do czystego wykonania. Biznes wyskalował się dobrze, technologia musiała nadgonić ambicje.

W innym przypadku, platformie SaaS dla operatorów wielooddziałowych, produkt miał wyraźne dopasowanie do rynku, realne koszty zmiany dostawcy i stabilny zespół. Badanie ujawniło, że krytyczna wiedza o systemie, obsłudze incydentów, logice integracji i procedurach wdrożeniowych, była skoncentrowana w kilku osobach bez sformalizowanej odpowiedzialności. Typowe w spółkach prowadzonych przez założycieli, ale istotnie zmieniające profil ryzyka po przejęciu. Ciągłość działania trzeba zaprojektować, nie można jej zakładać.

Trzeci przykład, platforma SaaS z silną bazą klientów w regionie CEE, wyglądał solidnie od strony retencji i roadmapy produktowej. Pod maską okazało się, że zarządzanie zależnościami i wersjonowanie komponentów open source nie były ustandaryzowane, a dojrzałość procesu CI/CD odstawała od skali platformy. Część modułów była w dobrym stanie, inne niosły nagromadzony dług, niewidoczny z zewnątrz. Nic, czego nie da się naprawić, ale trzeba to wpisać do planu po zamknięciu transakcji, zanim zapadną zobowiązania.

Wspólny mianownik jest taki, że w każdym z tych przypadków metryki biznesowe nie sygnalizowały problemu. Dług technologiczny nie pojawia się w raporcie przychodów, dopóki nie zacznie ograniczać wzrostu, a wtedy jest już częścią kosztu, który poniósł kupujący.

Jak wygląda dobrze poprowadzona ocena

Ograniczeniem w transakcji jest czas. Okno na badanie techniczne jest wąskie i musi zmieścić się w harmonogramie procesu, dlatego ocena długu technologicznego powinna być zaprojektowana jak element transakcji, a nie jak projekt konsultingowy. W praktyce dobrze poprowadzone badanie mieści się w dwóch tygodniach i przebiega w czterech etapach.

Pierwsze dwa dni to mandat i ustalenie zakresu: briefing dotyczący tezy inwestycyjnej, zapewnienie dostępów i zdefiniowanie obszarów priorytetowych. Od trzeciego do ósmego dnia trwa analiza wspomagana sztuczną inteligencją: skanowanie bazy kodu, zależności, bezpieczeństwa i infrastruktury, weryfikowane przez inżynierów. Od dziewiątego do dwunastego dnia odbywają się pogłębione sesje z kierownictwem inżynierskim i ocena dojrzałości zespołu. Ostatnie dni to raport i prezentacja dla komitetu inwestycyjnego.

Wykorzystanie sztucznej inteligencji na etapie analizy skraca czas rozpoznania o około 60 procent, ale nie zastępuje osądu. Narzędzia mapują zależności i wychwytują wzorce w kodzie znacznie szybciej niż człowiek, natomiast ocena, czy dane ustalenie zagraża tezie inwestycyjnej, pozostaje pracą doświadczonych inżynierów. To rozróżnienie jest tym, co pozwala połączyć krótki harmonogram z rzetelną głębią.

Po stronie spółki badanej potrzeba mniej, niż zwykle się zakłada: dostęp tylko do odczytu do repozytoriów kodu i konsoli chmurowej oraz dwie do trzech sesji z dyrektorem technicznym lub osobą kierującą inżynierią. Całość odbywa się po podpisaniu umowy o poufności, przed wymianą jakichkolwiek informacji o transakcji.

Czego ocena długu nie obejmuje

Uczciwe badanie ma jasno wyznaczone granice. Techniczne due diligence koncentruje się na technologii, infrastrukturze, bezpieczeństwie i zdolnościach zespołu inżynierskiego. Nie zastępuje walidacji modelu finansowego, analizy wielkości rynku, badania sporów dotyczących własności intelektualnej, weryfikacji przeszłości założycieli ani komercyjnego due diligence. Wartość powstaje wtedy, gdy ustalenia techniczne są uzgadniane ze strumieniem komercyjnym, a nie prowadzone równolegle bez kontaktu. Dobry dostawca badania technicznego potrafi zintegrować swoje wnioski z pracą doradcy komercyjnego, tak aby komitet inwestycyjny dostał jeden spójny obraz, a nie dwa niepowiązane dokumenty.

Osobną kwestią jest niezależność. Ocena długu technologicznego ma sens tylko wtedy, gdy jej autor nie ma interesu w tym, żeby dług wypadł większy lub mniejszy, niż jest w rzeczywistości. Dlatego znaczenie ma model rozliczenia i przejrzystość powiązań: stałe honorarium bez zachęt do dalszej współpracy oraz ujawnienie wcześniejszych relacji ze spółką badaną, a w razie istotnego konfliktu rezygnacja z mandatu.

Podejście Altimi

Altimi realizuje techniczne due diligence po stronie kupującego dla funduszy private equity, venture capital i inwestorów wzrostowych w Europie. Badanie jest dostarczane w stałej cenie i w ustalonym z góry zakresie, w ciągu dwóch tygodni, a rezultatem jest komplet materiałów przygotowanych z myślą o komitecie inwestycyjnym: około pięćdziesięciostronicowy raport z oceną w skali czerwony, bursztynowy, zielony, macierz ryzyka z rekomendacją go lub no-go, ocena skalowalności i dojrzałości AI, ocena dojrzałości zespołu i dostarczania oraz dziewięćdziesięciodniowa roadmapa tworzenia wartości. Do tego dochodzi prezentacja dla komitetu i przewidziane rundy korekt.

Dorobek to ponad sto badań po stronie kupującego w segmentach SaaS, FinTech, HealthTech i przemysłowym deep tech, wsparty ponad stu pięćdziesięcioma projektami inżynierskimi. Ta druga liczba ma znaczenie praktyczne: zespół, który na co dzień buduje i modernizuje systemy, inaczej ocenia realny koszt naprawy niż zespół, który wyłącznie audytuje. Ponieważ Altimi jako partner technologiczny łączy kompetencje w obszarach Product i Application Engineering, DevOps i Cloud Security oraz AI i Data Enablement, rekomendowane działania naprawcze może następnie wykonać ten sam zespół, co obniża realny koszt wdrożenia wniosków z badania.

Niezależność jest tu zasadą operacyjną, a nie deklaracją. Altimi działa wyłącznie na rzecz inwestora, na stałym honorarium bez zachęt do dalszych zleceń, ujawnia wcześniejsze powiązania ze spółką badaną i nie przyjmuje mandatów obarczonych istotnym konfliktem interesów. Aktualny zakres i cena badania są opublikowane na stronie poświęconej technicznemu due diligence.

Uwaga dla funduszy w Europie i regionie CEE

Dla funduszy działających w Polsce, regionie CEE oraz na rynkach niemieckojęzycznych ocena długu technologicznego ma dodatkowy wymiar regulacyjny. Ekspozycja na RODO, wymagania wynikające z norm takich jak ISO 27001 czy SOC 2 oraz oczekiwania klientów korporacyjnych co do bezpieczeństwa przekładają się bezpośrednio na dostępny rynek spółki przejmowanej. Luka w tym obszarze nie jest technicznym przypisem, tylko ograniczeniem wzrostu, które trzeba wycenić.

Znaczenie ma też to, gdzie fizycznie trafiają dane transakcyjne i kod źródłowy w trakcie badania. Współpraca z partnerem z siedzibą w Unii Europejskiej, posiadającym certyfikat ISO 27001, pozwala utrzymać wrażliwe materiały w europejskim obszarze ochrony danych przez cały poufny proces. Przy transakcjach transgranicznych, gdzie spółka przejmowana działa w jednym kraju, a fundusz raportuje w innym, ten aspekt bywa równie istotny co sama treść ustaleń.

Podsumowanie

Dług technologiczny jest ryzykiem wyjątkowym w tym sensie, że jest w pełni policzalny przed podpisaniem umowy, a mimo to najczęściej zostaje odkryty po niej. Ocena, która ma realną wartość dla inwestora, zaczyna się od tezy inwestycyjnej, przechodzi systematycznie przez osiem obszarów, w których dług wpływa na zdolność spółki do wzrostu, i kończy się nie opisem, lecz liczbą: oszacowanym nakładem naprawy, uporządkowaną macierzą ryzyka i planem na pierwsze dziewięćdziesiąt dni po zamknięciu transakcji.

Każde ustalenie ujawnione przed podpisaniem jest albo korektą ceny na korzyść funduszu, albo elementem planu, który fundusz świadomie finansuje. Każde ustalenie odkryte po zamknięciu jest wyłącznie kosztem. Cała różnica sprowadza się do tego, kto policzył dług pierwszy.

Jeśli masz aktywną transakcję i chcesz poznać zakres oraz harmonogram badania, najprościej zacząć od krótkiej rozmowy o spółce, którą masz przed sobą.

‍