Pre-exit readiness: jak w 90 dni przygotować spółkę portfelową do technicznego due diligence kupującego

W skrócie Przy większości wyjść z inwestycji zespół kupującego prowadzący techniczne due diligence już po kilku dniach wie to, z czym sprzedający żyje od lat: które moduły są kruche, jakie podatności nie zostały załatane, czego brakuje w dokumentacji i które kilka osób trzyma cały system w głowie. Gdy takie ustalenia wychodzą na jaw na późnym etapie procesu, rzadko przekreślają transakcję, ale niemal zawsze kosztują: obniżką ceny, dodatkowymi klauzulami indemnifikacyjnymi lub rachunkiem escrow. Uporządkowany, 90-dniowy program przygotowania odwraca tę dynamikę. Pozwala rzetelnie ocenić stan wyjściowy, naprawić to, co realnie wpływa na wycenę, udokumentować to, czego nie da się naprawić na czas, i przygotować opowieść o technologii, zanim napisze ją kupujący. W tym artykule pokazujemy, co sprawdzają kupujący, jak zaplanować te 90 dni i jakich błędów unikać.

Dlaczego sprzedający tracą na wartości podczas due diligence kupującego

Techniczne due diligence po stronie kupującego służy temu, by znaleźć argumenty za korektą ceny. To nie cynizm, tylko istota tego zadania. Każde nieudokumentowane ryzyko staje się kartą przetargową, a zwykle wychodzi na jaw w najmniej korzystnym momencie: w okresie wyłączności, gdy sprzedający ma niewielkie pole manewru i mało czasu na reakcję.

Utrata wartości przebiega zazwyczaj według znanego schematu:

• Późne ujawnienie. Na trzy tygodnie przed podpisaniem umowy wychodzi na jaw krytyczna podatność albo licencja copyleft w kluczowym module. Nie ma już czasu na naprawę, więc kupujący uwzględnia ryzyko w cenie, często z dużym zapasem.
• Dyskonto za niepewność. Gdy brakuje dokumentacji, kupujący nie jest w stanie sprawdzić, co działa dobrze. Mocne strony, których nie da się zweryfikować, traktuje się jak ryzyka.
• Zależność od kluczowych osób. Jeśli tylko jeden lub dwóch programistów rozumie krytyczne części systemu, kupujący zażąda programów retencyjnych, earn-outu albo niższej ceny.
• Niespójne odpowiedzi. CTO mówi jedno w prezentacji zarządu, w data roomie jest drugie, a programista w rozmowie mówi trzecie. Niespójność podważa zaufanie szybciej niż jakiekolwiek pojedyncze ustalenie.

Źródłem problemu jest asymetria informacji działająca na niekorzyść sprzedającego. Doradcy kupującego mają na koniec często jaśniejszy obraz technologii niż zarząd czy rada nadzorcza sprzedającej spółki. Właśnie temu ma zapobiec pre-exit readiness.

Co naprawdę sprawdzają kupujący

Większość technicznych badań due diligence po stronie kupującego, niezależnie od tego, czy prowadzi je fundusz private equity, inwestor strategiczny czy ich doradcy, obejmuje podobny zakres. Znajomość tych obszarów z wyprzedzeniem to połowa przygotowań.

Architektura i skalowalność. Czy platforma udźwignie plan wzrostu z modelu inwestycyjnego kupującego, czy będzie wymagała kosztownej przebudowy?

Jakość kodu i dług technologiczny. Na ile kod jest łatwy w utrzymaniu, jaka jego część jest objęta testami automatycznymi i gdzie znajdują się miejsca, które spowalniają rozwój?

Bezpieczeństwo i zgodność z regulacjami. Otwarte podatności, wyniki testów penetracyjnych, zarządzanie sekretami, kontrola dostępu, reagowanie na incydenty oraz certyfikaty, takie jak ISO 27001 czy SOC 2. Do tego dochodzi zgodność z RODO, a w przypadku wielu spółek także wymogi dyrektywy NIS2 i przepisów, które ją wdrażają.

Własność intelektualna i open source. Ryzyka licencyjne w zależnościach oraz kompletny łańcuch praw do kodu napisanego przez pracowników i współpracowników.

Infrastruktura i koszty. Architektura chmurowa, niezawodność, odtwarzanie po awarii oraz to, czy koszty hostingu rosną proporcjonalnie do przychodów.

Zespół i organizacja pracy. Zależność od kluczowych osób, ryzyko odejść, praktyki inżynierskie oraz wskaźniki pracy zespołu, takie jak częstotliwość wdrożeń czy odsetek wdrożeń kończących się awarią (change failure rate).

Dojrzałość w obszarze AI. Kupujący coraz częściej pytają również, czy zespół korzysta z AI w sposób kontrolowany i czy produkt ma wiarygodną roadmapę rozwoju AI.

Sprzedający, który sam przeanalizował każdy z tych obszarów równie wnikliwie jak kupujący, rzadko daje się zaskoczyć.

Plan na 90 dni

Dziewięćdziesiąt dni wystarczy, by wyraźnie zmienić wynik due diligence kupującego, pod warunkiem że czas zostanie wykorzystany we właściwej kolejności: najpierw zrozumieć, potem naprawić, na końcu uporządkować i przygotować materiały.

Dni 1–30: rzetelna ocena stanu wyjściowego

Pierwszy miesiąc służy temu, by spojrzeć na spółkę tak, jak zobaczy ją kupujący. Najskuteczniejszym narzędziem jest próbne techniczne due diligence (mock DD), przeprowadzone przez niezależny zespół według tej samej metodyki, jaką zastosowaliby doradcy kupującego. Wewnętrzna samoocena rzadko się tu sprawdza, ponieważ osoby, które zbudowały system, najtrudniej dostrzegają jego słabości.

Wynikiem tego etapu powinny być:

• spis wszystkich systemów, repozytoriów, środowisk i zależności od dostawców zewnętrznych,
• rejestr ustaleń obejmujący wszystkie obszary badane przez kupujących,
• ocena wagi każdego ustalenia i szacunek nakładu pracy potrzebnego do jego usunięcia,
• wstępna ocena tego, jak poszczególne ustalenia mogą wpłynąć na wycenę.

Efektem tej fazy nie jest raport, lecz lista decyzji. Każde ustalenie trafia do jednej z trzech ścieżek: naprawić przed sprzedażą, udokumentować wraz z planem naprawczym albo ujawnić jako znane ograniczenie.

Dni 31–60: naprawa tego, co wpływa na cenę

Drugi miesiąc poświęcony jest naprawom, ale tylko tam, gdzie to się opłaca. Celem nie jest idealny system, lecz usunięcie tych ustaleń, które kupujący wykorzystałby do obniżenia ceny. Typowe priorytety to:

• krytyczne i poważne podatności bezpieczeństwa, a następnie nowy test penetracyjny, dzięki któremu w data roomie znajdzie się aktualny raport bez istotnych zastrzeżeń,
• zarządzanie sekretami i kontrola dostępu, w tym usunięcie danych uwierzytelniających zapisanych na stałe w kodzie i ograniczenie dostępu uprzywilejowanego,
• problemy z licencjami open source i brakujące umowy przenoszące prawa, które wcześnie zwykle łatwo i tanio rozwiązać, a późno trudno i kosztownie wytłumaczyć,
• krytyczny dług technologiczny w modułach wysokiego ryzyka, zwłaszcza tam, gdzie zależy od nich plan wzrostu kupującego,
• testy automatyczne dla procesów krytycznych biznesowo, które pokazują, że system można bezpiecznie zmieniać,
• szybkie oszczędności w kosztach chmury, ponieważ nieefektywne wydatki na infrastrukturę bezpośrednio obniżają marżę, za którą płaci kupujący.

Naprawy muszą przebiegać równolegle z realizacją roadmapy produktowej, a nie zamiast niej. Wyraźne spowolnienie rozwoju produktu w miesiącach poprzedzających wyjście z inwestycji samo w sobie jest negatywnym sygnałem. Zewnętrzne wsparcie przy naprawach, na przykład w ramach rozwoju produktów i aplikacji lub ukierunkowanych usług z zakresu DevOps, bezpieczeństwa chmury i usług zarządzanych, pozwala zespołowi podstawowemu dalej rozwijać produkt.

Dni 61–90: przygotowanie opowieści o technologii

W ostatnim miesiącu wykonaną pracę przekłada się na materiały, które kupujący może szybko zweryfikować. To etap, na który wielu sprzedających poświęca za mało uwagi, choć dobrze uporządkowane dowody skracają due diligence kupującego i zostawiają mniej miejsca na spekulacje.

Pakiet technologiczny gotowy dla kupującego obejmuje zwykle:

• uporządkowany techniczny data room z diagramami architektury, specyfikacjami systemów, wykazem zależności, raportami bezpieczeństwa, politykami i certyfikatami,
• rejestr znanych ograniczeń, w którym pozostałe słabości są opisane wraz z realistycznymi planami naprawczymi, szacunkami pracochłonności i osobami odpowiedzialnymi,
• techniczne FAQ, które z wyprzedzeniem odpowiada na najbardziej prawdopodobne pytania kupujących i jest spójne z zawartością data roomu,
• środowisko demonstracyjne, które działa niezawodnie i pokazuje produkt z najlepszej strony, nie ujawniając danych produkcyjnych,
• część technologiczną prezentacji zarządu, która wyjaśnia architekturę, roadmapę i zespół językiem biznesu,
• przygotowane kluczowe osoby. CTO i doświadczeni programiści powinni wiedzieć, jakie tematy się pojawią, jakie odpowiedzi zostały uzgodnione i gdzie znajdują się dowody.

Naprawić, udokumentować czy ujawnić: jak podjąć właściwą decyzję

Nie każde ustalenie wymaga takiego samego podejścia. Decyzja zależy od tego, jak istotna jest dana kwestia dla kupującego i czy można ją realnie rozwiązać przed rozpoczęciem procesu.

W przypadku większych problemów strukturalnych AI Refactoring Assessment pozwala oszacować nakład pracy i ryzyko modernizacji. Znany i wyceniony problem jest dla kupującego znacznie łatwiejszy do zaakceptowania niż otwarte pytanie.

Najczęstsze błędy, które kosztują sprzedających

Rozpoczęcie dużej przebudowy tuż przed sprzedażą. Niedokończoną migrację trudniej wycenić niż zarówno stary, jak i nowy system. Duże programy modernizacyjne powinny zostać zakończone odpowiednio wcześnie albo przedstawione jako plan.

Ukrywanie problemów. Doświadczone zespoły po stronie kupującego znajdują większość istotnych kwestii. Problem ujawniony przez sprzedającego jest punktem negocjacji, a problem wykryty przez kupującego podważa wiarygodność.

Dbanie wyłącznie o pozory. Atrakcyjna dokumentacja, która nie odpowiada rzeczywistemu stanowi kodu, szybko zostaje zdemaskowana. Dowody muszą odzwierciedlać rzeczywistość.

Pozostawienie CTO samego z całym procesem. Due diligence kupującego jest intensywne. Bez przygotowania i wsparcia kierownictwo techniczne staje się wąskim gardłem, a na tym cierpi bieżąca działalność.

Pomijanie wskaźników pracy zespołu. Kupujący coraz częściej oczekują danych, a nie opinii. Możliwość wykazania częstotliwości wdrożeń, czasu realizacji zmian i odsetka wdrożeń kończących się awarią, najlepiej w ujęciu historycznym, czyni opowieść o zespole inżynierskim znacznie bardziej wiarygodną. Ten obraz może dodatkowo wzmocnić uporządkowane wdrożenie AI w pracy zespołów programistycznych, pod warunkiem że jego efekty są mierzone, a nie tylko deklarowane.

Opowiedz historię swojej technologii, zanim zrobi to kupujący

Przy każdym wyjściu z inwestycji ktoś przedstawia komitetowi inwestycyjnemu kupującego technologię przejmowanej spółki. Pytanie brzmi tylko, czy sprzedający będzie miał wpływ na ten opis, czy doradcy kupującego napiszą go sami. Program przygotowania na 90 dni daje zarządowi fakty, naprawy i dowody potrzebne do tego, by samodzielnie prowadzić tę rozmowę.

Korzyść rzadko sprowadza się do jednej spektakularnej liczby. To sprawniejszy proces, mniej argumentów za obniżką ceny, węższy zakres klauzul indemnifikacyjnych, krótszy okres wyłączności i zarząd, który z pewnością siebie odpowiada na trudne pytania. Jeśli planujesz wyjście z inwestycji w ciągu najbliższych 6–12 miesięcy, porozmawiajmy o tym, jak nasz zespół technicznego due diligence przeprowadzi próbne badanie i przygotuje spółkę do tego właściwego.