Inwestorzy nie oceniają twojego kodu. Wyceniają ryzyko, że technologia zatrzyma plan, który finansują — a założyciele, którzy to rozumieją, przygotowują się zupełnie inaczej.
Założyciele szykujący się do technicznego due diligence często polerują nie to co trzeba — sprzątają kod, piszą dokumentację, o którą nikt nie prosił, martwią się wyborem frameworka. Inwestorzy zadają zupełnie inne pytanie: co może pójść źle po stronie technologii i powstrzymać tę firmę przed osiągnięciem kamieni milowych z planu?
Cztery rzeczy, które faktycznie są oceniane
1. Czy skaluje się do planu (a nie w nieskończoność)
Nikt nie oczekuje od firmy na Series A architektury Google'a. Pytanie jest węższe: czy system przetrwa konkretny wzrost z modelu, a jeśli nie, ile kosztuje podniesienie tego sufitu? Jasna, wyceniona odpowiedź to mocny sygnał. «Powinno być w porządku» nim nie jest.
2. Ryzyko osoby kluczowej
Często najbardziej decydujące ustalenie i to, którego założyciele najmniej się spodziewają. Jeśli jeden inżynier trzyma całą krytyczną wiedzę, inwestycja niesie ryzyko niemające nic wspólnego z jakością kodu. Inwestorzy sondują to wprost: kto inny mógłby prowadzić ten system w przyszłym tygodniu, gdyby ta osoba odeszła?
3. Czy technologia faktycznie należy do was
- Praca kontraktorów bez podpisanego przeniesienia IP — problem prawny, który może opóźnić albo zabić zamknięcie
- Skażenie licencyjne open source w produkcie zamkniętym
- Krytyczna zależność od dostawcy, który może zmienić ceny, ograniczyć dostęp albo zniknąć
- Ile z «własnej technologii» to cienka warstwa nad cudzym API
4. Zdolność dostarczania
To przewiduje kolejne dwa lata lepiej niż obecny stan bazy kodu. Inwestorzy patrzą na częstotliwość wdrożeń, sposób, w jaki zmiany trafiają na produkcję, czy incydenty są wykrywane wewnętrznie i czy zespół udźwignie rekrutacje zakładane w planie.
Jak się przygotować (w cztery tygodnie przed)
- Spisz uczciwy rejestr ryzyk technicznych — co jest słabe, co blokuje, ile kosztuje naprawa. Podanie tego z własnej woli czyta się jako kompetencję; przyłapanie na ukrywaniu — odwrotnie.
- Napraw najpierw wszystko z kategorii pieniądze i dane — to te ustalenia stają się warunkami transakcji.
- Zamknij luki w IP: podpisane przeniesienia od każdego kontraktora, przegląd licencji zależności.
- Widocznie zmniejsz bus factor — dołącz kogoś do krytycznego systemu, spisz rejestr decyzji architektonicznych.
- Przygotuj klarowne omówienie architektury: czym jest, dlaczego, gdzie pęka, jaki jest plan.
Jak ustalenia przekładają się na warunki
| Ustalenie | Typowy skutek |
|---|---|
| Pieniądze mogą być po cichu błędne (brak księgi) | Naprawa sfinansowana w rundzie; czasem w transzach |
| Wyciek danych między najemcami | Warunek zamknięcia — naprawić przed uwolnieniem środków |
| Niejasne IP od kontraktorów | Wymagane uporządkowanie prawne przed zamknięciem |
| Bus factor jeden | Pakiet retencyjny albo zobowiązanie rekrutacyjne w planie |
| Ręczne wdrożenia, brak rollbacku | Wycenione w 90-dniowym planie po zamknięciu |
| Starzejące się zależności, cienka dokumentacja | Odnotowane, bez konsekwencji |
Inwestorzy nie oczekują idealnego systemu. Oczekują założyciela, który dokładnie wie, które części są niedoskonałe i ile kosztuje ich naprawa.
Powiąż każde ustalenie z decyzją
Wyjaśnij, które założenia pozostają wiarygodne i co zmienia plan. Pokaż niepewność obok nakładu naprawy.
- Wskaż założenie biznesowe i sprawdzone dowody.
- Opisz skutek, niepewność i zależności naprawy.
- Oddziel warunek transakcji, pozycję budżetu i akceptowane ryzyko.
Najczęstsze pytania
Ile trwa techniczne due diligence inwestora?
Zwykle tydzień do dwóch przy Series A, dłużej przy fintechu, healthtechu albo nietypowo dużych systemach. Zwykle obejmuje dostęp do repozytorium, omówienie architektury i rozmowy z zespołem inżynierskim.
Czy założyciele powinni zrobić własny audyt techniczny przed rundą?
Często tak. Ustalenia, które sam wyciągniesz, stają się planem naprawczym, który kontrolujesz; te same ustalenia wyciągnięte przez doradcę inwestora stają się pozycją negocjacyjną przeciw tobie. Koszt audytu przed rundą jest mały wobec wpływu na wycenę, któremu może zapobiec.
Czy bałaganiarski kod zabije naszą rundę?
Rzadko sam z siebie. Na transakcje wpływają ustalenia z konsekwencją — integralność pieniędzy, ekspozycja bezpieczeństwa, niejasna własność IP i ryzyko osoby kluczowej. Inwestorzy widzieli niedoskonałości każdej bazy kodu; niepokoi ich zespół, który nie potrafi trafnie opisać własnych ryzyk.
Czy wystarczy jedna ocena techniczna?
Nie. Podsumowuje, ale ukrywa zakres i niepewność. Dodaj istotne ustalenia, niedostępne dowody i założenia wycen napraw.
Wkrótce zbierasz rundę?
Przeprowadzamy diligence, zanim zrobi to twój inwestor — żeby ustalenia przyszły z twoim planem naprawczym w załączniku.
Warto doczytać
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?
Audyt kodu przed inwestycją: o co prosić, zanim przelejesz pieniądze
Za chwilę kupisz udział w aktywie, którego nie obejrzałeś. Audyt kodu jest tymi oględzinami — ale tylko wtedy, gdy jest zakrojony pod pytania inwestycyjne, a nie inżynierskie.