Due diligence techniczne dla inwestorów

Nowe pytanie inwestora

„Zanim wypiszemy czek, chcielibyśmy wprowadzić assessora technicznego”.

To pytanie staje się standardem w transakcjach VC i M&A. Coraz więcej inwestorów zatrudnia niezależnych konsultantów technicznych do oceny technologii, zespołu i architektury firm, które rozważają sfinansować.

Jeśli pozyskujesz kapitał, musisz być na to gotowy. Nie dlatego, że twoja technologia jest zła - ale dlatego, że nieprzygotowani founderzy oblać mogą due diligence techniczne nawet przy solidnym produkcie.

Pięć wymiarów

1. Dojrzałość architektury

Inwestorzy chcą wiedzieć, czy masz prototyp czy system produkcyjny - i czy architektura udźwignie skalę, którą obiecujesz.

Czego szukają:

• Jak dane płyną przez system
• Czy architektura pasuje do etapu (monolit jest w porządku na wczesnym etapie; nadmiernie zinżynieryjowane mikroserwisy dla 3-osobowego zespołu to czerwona flaga)
• Jak system obsługuje awarię (obsługa błędów, fallbacki, monitoring)
• Czy istnieje pipeline wdrożeniowy, środowisko staging i możliwość wycofania

Co zabija transakcję:

• „Produkcyjny” system wymagający ręcznego wdrożenia
• Brak monitoringu lub alertowania
• Architektura zaprojektowana pod skalę, która nie istnieje (przedwczesna optymalizacja)
• Pojedynczy serwer uruchamiający wszystko (włącznie z bazą danych)

2. Możliwości zespołu

Inwestorzy oceniają, czy zespół potrafi zrealizować mapę drogową. Nie oceniają indywidualnych umiejętności - oceniają, czy zbiorczy zespół pasuje do problemu.

Czego szukają:

• Czy członkowie zespołu wdrażali podobne systemy wcześniej?
• Czy jest lider techniczny potrafiący komunikować się z nietechnicznymi interesariuszami?
• Czy zespół ma relewantną ekspertyzę domenową, czy uczy się w trakcie?
• Jaki jest współczynnik autobusowy (bus factor) - ilu ludzi może utrzymać system, jeśli jedna osoba odejdzie?

Co zabija transakcję:

• System AI zbudowany przez jedną osobę, która jest jedyną, co go rozumie
• Doświadczenie zespołu niepasujące do problemu (dwóch junior deweloperów budujących rozproszony platformę AI)
• Nikt nie potrafi wyjaśnić decyzji technicznych prostym językiem
• Kluczowi członkowie zespołu planują odejść po finansowaniu

3. Jakość kodu

Inwestorzy nie czytają twojego kodu linia po linii. Szukają sygnałów wskazujących, czy baza kodu jest zdrowa, czy katastrofą utrzymaniową czekającą na moment.

Czego szukają:

• Pokrycie testami (nie 100%, ale znaczące testy dla ścieżek krytycznych)
• Organizacja kodu - czy nowy deweloper rozumie strukturę
• Zarządzanie zależnościami - ile pakietów stron trzecich, czy są utrzymywane
• Dokumentacja - czy jakaś jest, czy wiedza jest w głowach ludzi

Co zabija transakcję:

• Brak testów w ogóle dla ścieżek krytycznych dla przychodu
• Plik 100 000 linii „robiący wszystko”
• Zależności od nieutrzymywanych pakietów (ryzyko bezpieczeństwa)
• Brak dokumentacji poza komentarzami kodu sprzed roku
• Hardkodowane poświadczenia, klucze API lub URL-e baz danych w bazie kodu

4. Ryzyko zależności

Inwestorzy coraz bardziej wyczuleni na startupy zależne od pojedynczego dostawcy, API lub platformy, które mogą zmienić cennik, warunki lub dostępność.

Czego szukają:

• Czy jesteś przywiązany do pojedynczego dostawcy AI (OpenAI, Anthropic)?
• Czy możesz przełączyć, jeśli ceny znacząco wzrosną?
• Czy twoje dane są przechowywane w systemie, który kontrolujesz?
• Co się stanie, jeśli twój dostawca chmury ma awarię?

Co zabija transakcję:

• Cały produkt to cienka obudowa wokół GPT, bez własnych danych ani technologii
• Brak planu awaryjnego, gdy API AI padnie
• Dane przechowywane w systemie strony trzeciej bez możliwości eksportu
• Pojedynczy dostawca chmury bez wieloregionalnej kopii zapasowej

5. Postawa bezpieczeństwa

W erze rosnących regulacji (EU AI Act, GDPR, CCPA) inwestorzy muszą wiedzieć, że nie nosisz egzystencjalnego ryzyka bezpieczeństwa.

Czego szukają:

• Praktyki uwierzytelniania i autoryzacji
• Szyfrowanie danych (w spoczynku i w tranzycie)
• Obsługa PII i polityki retencji danych
• Ryzyka specyficzne dla AI (prompt injection, wyciek danych)
• Dokumentacja zgodności dla relewantnych regulacji

Co zabija transakcję:

• Dane klientów wysyłane do API AI bez anonimizacji
• Brak przeglądu bezpieczeństwa systemu AI
• Brak planu reakcji na incydenty
• „Zajmiemy się zgodnością później” - zwłaszcza dla EU AI Act lub GDPR

Jak się przygotować

Zanim zapytają

Udokumentuj architekturę. Jeden diagram, aktualizowany kwartalnie. Przepływ danych, granice systemu, infrastruktura wdrożeniowa. Jeśli nie potrafisz go narysować, nie rozumiesz go dostatecznie.

Udokumentuj kluczowe decyzje techniczne. Dlaczego wybrałeś tę bazę danych? Dlaczego ten model AI? Dlaczego tę architekturę? Log decyzji wyjaśniający rozumowanie jest wart więcej niż perfekcyjny kod.

Zidentyfikuj zależności. Wypisz każdą usługę, API i dostawcę strony trzeciej. Dla każdej: co się stanie, jeśli podwoją cenę, będą niedostępni 24 godziny lub wycofają usługę.

Zrób audyt przed-DD. Zatrudnij niezależnego assessora technicznego przed inwestorem. Lepiej odkryć i naprawić problemy samemu, niż by assessor inwestora je odkrył.

W trakcie due diligence

Bądź przejrzysty w tym, czego nie wiesz. „Jeszcze tego nie adresowaliśmy, oto nasz plan” jest lepsze niż „mamy to pokryte” - aż odkryją, że nie.

Przyprowadź osobę techniczną dobrze komunikującą. Assessor będzie chciał porozmawiać z kimś, kto potrafi wyjaśnić architekturę. Jeśli twój CTO jest bierny lub twój główny inżynier nie potrafi tłumaczyć nietechnicznym, assessor to zflaguje.

Pokaż dokumentację. Udokumentowany system sygnalizuje dojrzałość. Niedokumentowany, który zespół potrafi wyjaśnić ustnie, sygnalizuje ryzyko.

Checklista przygotowawcza

• Diagram architektury (stan obecny, nie aspiracyjny)
• Log decyzji dla kluczowych wyborów technicznych
• Mapa zależności z planami awaryjnymi
• Raport pokrycia testami dla ścieżek krytycznych
• Dokumentacja przeglądu bezpieczeństwa
• Klasyfikacja zgodności (EU AI Act, GDPR)
• Macierz możliwości zespołu vs wymogi mapy drogowej
• Dokumentacja wdrożeniowa i reakcji na incydenty

Jeśli tego nie masz, zacznij budować teraz. Due diligence techniczne nie jest już opcjonalne - jest częścią procesu pozyskiwania funduszy.

FAQ

Kiedy zacząć przygotowania do due diligence technicznego? Gdy tylko zaczniesz pozyskiwać kapitał. Dokumentacja zajmuje 2-4 tygodnie i powinna być aktualizowana wraz z ewolucją systemu. Nie czekaj na term sheet.

Co jeśli oblać due diligence techniczne? To nie koniec transakcji - to punkt negocjacyjny. Inwestor może zażądać audytu technicznego jako warunku finansowania, albo skorygować wycenę. Przejrzysta odpowiedź („zidentyfikowaliśmy te problemy, oto plan naprawy”) jest lepsza niż próba ukrycia problemów.

Czy potrzebuję osobnego konsultanta due diligence technicznego? Jeśli inwestor przyprowadza własnego, ty też możesz chcieć swojego - by reprezentować twoją stronę i zapewnić uczciwość. Jeśli nie przyprowadzają, rozważ zatrudnienie takiego do przygotowania. Koszt (5-15 tys. €) jest mały względem wielkości transakcji.