Techniczne due diligence dla inwestorów: kompletny przewodnik

Techniczne due diligence to nie code review. To odpowiedź na jedno pytanie: ile będzie kosztowało doprowadzenie tej technologii tam, gdzie potrzebuje jej teza inwestycyjna?

Większość technicznych due diligence produkuje dokument, którego nikt nie używa. Wymienia frameworki, liczy testy, zauważa, że dokumentacja mogłaby być lepsza — a potem transakcja dochodzi do skutku albo nie, z zupełnie innych powodów. To zmarnowanie realnej okazji do wyceny ryzyka.

Użyteczne techniczne due diligence odpowiada na trzy pytania w kategoriach biznesowych: czy ta technologia udźwignie plan, który finansujesz, ile będzie kosztowało zamknięcie luk i które ryzyka mogą zniszczyć wartość, a nie tylko ją spowolnić.

Do czego naprawdę służy techniczne due diligence

Inwestor venture nie kupuje bazy kodu. Kupuje tezę: ten zespół osiągnie tę skalę w tym czasie. Technologia liczy się tylko tam, gdzie czyni tę tezę bardziej lub mniej prawdopodobną.

Pięć obszarów, które mają znaczenie

1. Architektura i zapas na skalowanie

Każdy system ma sufit. Pytanie brzmi, gdzie leży względem planu i ile kosztuje jego podniesienie. Monolit obsługujący spokojnie 100 tys. użytkowników nie jest ustaleniem; monolit z jedną bazą master-do-zapisu i planem wzrostu do 10 milionów — już tak.

• Pojedyncze punkty awarii — i czy zespół wie, które to
• Warstwa danych — zwykle prawdziwy sufit i najdroższa rzecz do zmiany później
• Czy obciążenie kiedykolwiek testowano, czy skalowanie jest założeniem
• Krzywa kosztów chmury: czy unit economics przetrwa 10×, czy infrastruktura zje marżę?

2. Integralność pieniędzy i danych

Dla każdej firmy dotykającej płatności, sald lub danych regulowanych to obszar o najwyższym koszcie błędu — i ten najczęściej pomijany, bo jego inspekcja wymaga wiedzy dziedzinowej.

• Czy saldo wyprowadzane jest z niezmiennej księgi, czy to zmienialna liczba, którą kod może nadpisać?
• Idempotencja na ścieżkach płatności i webhooków — czy ponowienie może obciążyć dwa razy?
• Pieniądze jako liczby całkowite w jednostkach podrzędnych, nigdy jako float
• Rekoncyliacja: czy rozbieżność zostałaby wykryta wewnętrznie, czy przez klienta?

3. Ekspozycja na bezpieczeństwo i zgodność

Ustalenia bezpieczeństwa mają sens tylko powiązane ze skutkiem. «Zależności są przestarzałe» to szum. «Nieuwierzytelniony endpoint zwraca rekordy innych najemców» to klauzula umowna.

• Autoryzacja egzekwowana po stronie serwera przy każdym żądaniu, nie schowana w interfejsie
• Izolacja multi-tenant — zdecydowanie najczęstsze poważne ustalenie w B2B SaaS
• Zarządzanie sekretami i czy poświadczenia leżą w historii gita
• Jakie dane regulowane są przechowywane — i czy w ogóle powinny
• Dystans do certyfikacji wymaganej przez go-to-market (SOC 2, ISO 27001, PCI DSS)

4. Zdolność dostarczania

To przewiduje kolejne dwa lata lepiej niż obecna baza kodu. Przeciętna baza kodu z silną dyscypliną dostarczania poprawia się. Elegancka baza kodu bez zdolności bezpiecznego wydawania — nie.

• Częstotliwość wdrożeń i czas dostarczenia małej zmiany
• Czy rollback to przećwiczona rutyna, czy teoria
• Pokrycie testami ścieżek, które mają znaczenie (pieniądze, auth), a nie globalny procent
• Wykrywanie incydentów: czy znajdują problemy przed klientami?

5. Ryzyko zespołu i osoby kluczowej

• Bus factor: ile osób rozumie krytyczne podsystemy — jeśli odpowiedź brzmi «jedna», to ryzyko transakcyjne
• Czy wiedza istnieje poza głowami
• Zależność od kontraktorów przy kluczowym IP i czy przeniesienie IP jest czyste
• Realizm planu rekrutacji wobec finansowanej roadmapy

Czerwone flagi uszeregowane według realnego kosztu

Celem technicznego due diligence nie jest znalezienie powodu do odejścia od stołu. Celem jest wiedzieć dokładnie, co kupujesz, żeby cena i plan to odzwierciedlały.

Jak ustalenia przekładają się na warunki transakcji

1. Budżet naprawczy — wycenić poprawki i sfinansować je jawnie w rundzie, zamiast odkrywać je w szóstym miesiącu
2. Warunki kamieni milowych — uwolnienie transzy powiązane z konkretną naprawą (typowe, gdy luki zgodności blokują go-to-market)
3. Korekta wyceny — tam, gdzie naprawa jest duża względem rundy
4. Plan po zamknięciu — 90-dniowa roadmapa techniczna uzgodniona przed przelewem, nie improwizowana po

Ile to trwa

Dłużej nie znaczy lepiej. Po dwóch tygodniach większość zleceń produkuje szczegóły zamiast decyzji — chyba że dziedzina naprawdę tego wymaga, jak płatności czy regulowane dane zdrowotne.

Ustal zakres przed zbieraniem dokumentów

Przegląd powinien odpowiadać tezie inwestycyjnej. Zdefiniuj pytania, istotne systemy i dowody przed oceną ryzyka.

1. Powiąż wzrost z dowodami pojemności i kosztów operacyjnych.
2. Oddziel deklaracje, potwierdzone testy i niedostępne informacje.
3. Rozróżnij warunki zamknięcia transakcji i finansowany plan późniejszy.

• audyt kodu przed inwestycją →
• techniczne due diligence inwestorzy →