Tech due diligence: jak przygotować startup, zanim fundusz zacznie pytać

Przygotowanie do tech due diligence zajmuje 4-6 tygodni i sprowadza się do jednego: na każde z 10 standardowych pytań funduszu masz mieć udokumentowaną odpowiedź, zanim padnie. DD nie szuka spółki bez długu technicznego, bo takie nie istnieją. Szuka founderów, którzy wiedzą, gdzie mają ryzyka i mają plan ich adresowania. Po 30+ procesach DD, które prowadziłem po stronie funduszy, poniżej opisuję, co dokładnie będzie sprawdzane i jak się do tego ustawić. Perspektywę inwestora opisałem osobno w tekście o tech due diligence dla VC, ten tekst jest lustrzany: dla foundera.

Fundusz nie ocenia elegancji kodu. Ocenia trzy ryzyka: czy technologia udźwignie plan wzrostu z pitch decka, czy zespół jest w stanie ją rozwijać i czy nie ma min, które wybuchną po przelewie (licencje, bezpieczeństwo, zależność od jednej osoby). Wszystkie pytania DD są wariantami tych trzech.

To zmienia optykę przygotowań: nie sprzątasz kodu na pokaz, tylko przygotowujesz odpowiedzi i dowody.

Architektura: fundusz pyta, czy system udźwignie 10x ruchu, przygotuj diagram architektury, znane wąskie gardła i plan skalowania. Dług techniczny: gdzie jest i ile kosztuje, przygotuj listę top 5 pozycji długu z wyceną w tygodniach pracy. Zespół: kto jest niezastępowalny, przygotuj mapę kompetencji, bus factor i plan sukcesji wiedzy. Delivery: jak przewidywalnie dowozicie, przygotuj dane z ostatnich 2 kwartałów, plan vs wykonanie. Bezpieczeństwo: jak chronicie dane, przygotuj polityki dostępów, szyfrowanie, historię incydentów i zgodność z RODO. Własność IP: czy kod należy do spółki, przygotuj umowy z przeniesieniem IP od pracowników, kontraktorów i software house'u. Licencje: czy open source nie zaraża produktu, przygotuj skan zależności i listę licencji copyleft z oceną ryzyka. Infrastruktura: ile kosztuje i jak rośnie z ruchem, przygotuj koszty cloud za 12 miesięcy i prognozę przy wzroście. Dokumentacja: czy wiedza jest w głowach czy na piśmie, przygotuj minimum: setup środowiska, architekturę, runbooki krytycznych procesów. Roadmapa: czy plan produktu ma pokrycie w zespole, przygotuj roadmapę na 12 miesięcy z estymacją zasobów.

Z procesów, w których uczestniczyłem, trzy znaleziska najczęściej obniżały wycenę albo zatrzymywały rozmowy:

Kod bez przeniesienia IP. Fragmenty produktu pisane przez kontraktorów lub software house bez umownego przeniesienia praw. To nie jest problem techniczny, tylko prawny, i fundusz potraktuje go zero-jedynkowo. Audyt umów zrób w pierwszym tygodniu przygotowań, bo naprawa wymaga podpisów, a nie kodu.

Bus factor równy jeden. Cały system rozumie jedna osoba, zwykle founder techniczny albo pierwszy inżynier. Fundusz widzi w tym ryzyko utraty całej wartości technologicznej wraz z jednym wypowiedzeniem. Odpowiedzią jest dokumentacja i celowe rozproszenie wiedzy, co trwa tygodnie, więc nie da się tego zrobić w noc przed DD.

Metryki delivery, które nie istnieją. Na pytanie "ile z planu kwartalnego dowieźliście" pada odpowiedź opisowa. Brak danych fundusz czyta jako brak kontroli. Jeśli nie zbieracie tych danych, zacznijcie natychmiast, nawet 6 tygodni historii jest lepsze niż zero.

Tydzień 1-2: audyt umów IP i skan licencji open source (największe ryzyka prawne naprzód), inwentaryzacja dokumentacji, start zbierania metryk delivery, jeśli ich nie ma. Tydzień 3-4: diagram architektury z zaznaczonymi wąskimi gardłami, wycena top 5 pozycji długu technicznego, mapa kompetencji zespołu. Tydzień 5-6: złożenie data roomu technicznego, próbne DD (ktoś z zewnątrz zadaje pytania funduszu, zespół odpowiada), poprawki.

Próbne DD to najtańszy element o największym zwrocie. Founderzy prawie zawsze wiedzą, co odpowiedzieć, ale odpowiedzi rozjeżdżają się między CTO a CEO, a to rozjazd, nie treść, budzi wątpliwości funduszu.

Kiedy zacząć przygotowania do tech DD? Minimum 4-6 tygodni przed pierwszymi rozmowami z inwestorami. Ryzyka prawne (IP, licencje) i braki w metrykach delivery wymagają tygodni na naprawę. Przygotowania zaczęte po otrzymaniu term sheeta oznaczają negocjowanie pod presją czasu z odkrytymi kartami.

Czy dług techniczny obniża wycenę? Sam dług rzadko. Wycenę obniża dług nieuświadomiony albo bagatelizowany. Founder, który pokazuje listę pozycji długu z wyceną i planem spłaty, buduje wiarygodność. Founder, który mówi "u nas nie ma długu", traci ją natychmiast, bo doświadczony audytor i tak go znajdzie.

Co jeśli produkt zbudował software house? To nie dyskwalifikuje, o ile spółka ma umowne przeniesienie IP, dostęp do repozytoriów i infrastruktury na własnych kontach oraz plan przejęcia rozwoju do środka. Brak któregokolwiek z tych trzech elementów to poważna flaga i temat do naprawy przed rundą.

Kto powinien odpowiadać na pytania podczas DD? Osoba odpowiedzialna za technologię: CTO, VP Engineering albo fractional CTO. Founder biznesowy odpowiadający samodzielnie na pytania techniczne to słaby sygnał, nawet przy dobrych odpowiedziach, bo fundusz ocenia też, kto będzie tę technologię prowadził po inwestycji.

Prowadzę audyty execution risk dokładnie w formule, w jakiej robi je fundusz: 10-punktowy readiness score, mapa ryzyk i plan 30/60/90 na ich adresowanie, w 1-2 tygodnie. Umów bezpłatny audyt, a w 30 minut ocenię, które obszary wymagają pracy przed twoją rundą. Szczegóły na stronie usług.