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.
Audyt kodu przed inwestycją mieści się w szerszym technicznym due diligence i ma węższe zadanie: ustalić, co faktycznie istnieje, czy własność jest czysta i czy to udźwignie finansowany plan.
Źle zakrojony produkuje listę zażaleń o styl. Dobrze zakrojony produkuje dwa lub trzy ustalenia, które zmieniają transakcję.
O jakie dostępy prosić
Poproś o nie przed podpisaniem term sheet. Opór na tym etapie sam w sobie wiele mówi.
- Dostęp do odczytu wszystkich repozytoriów — łącznie z infrastructure-as-code i skryptami wdrożeniowymi, gdzie często widać prawdziwy stan rzeczy
- Pełna historia commitów, nie spłaszczony zrzut: historia pokazuje, kto naprawdę zbudował system i jak szybko się on porusza
- Omówienie architektury z inżynierem, który ją zbudował, jedna–dwie godziny
- Dostęp do systemu zgłoszeń i, jeśli istnieją, do zapisów incydentów
- Lista usług zewnętrznych, od których zależy produkt
Osiem pytań, na które audyt musi odpowiedzieć
- Czy istniejący kod odpowiada temu, co opisano w pitchu? (Demoware i integracje będące w rzeczywistości procesami ręcznymi są częste.)
- Kto go napisał i czy te osoby wciąż tam są?
- Czy własność IP jest czysta — kontraktorzy z umową przeniesienia, brak nielicencjonowanego skopiowanego kodu, brak skażenia licencyjnego zależnościami GPL w produkcie zamkniętym?
- Co pęka pierwsze przy planie wzrostu i ile kosztuje przesunięcie tego sufitu?
- Czy dane klientów są izolowane między najemcami i czy autoryzacja jest egzekwowana po stronie serwera?
- Dla wszystkiego finansowego: czy jest niezmienna księga i czy każda ścieżka pieniędzy jest idempotentna?
- Czy zespół potrafi bezpiecznie wdrażać — automatyzacja, rollback, monitoring?
- Ile produktu naprawdę należy do nich, a ile to cienka nakładka na dostawców, którzy mogą zmienić ceny albo zniknąć?
Ustalenia uzasadniające zapis w umowie
| Ustalenie | Typowa konsekwencja |
|---|---|
| Rdzeń zbudowany przez kontraktorów bez przeniesienia IP | Zamknąć przed przelewem — środek prawny, nie techniczny |
| Brak księgi w firmie, która przesuwa pieniądze | Budżet naprawczy sfinansowany w rundzie; możliwe transze |
| Wyciek danych między najemcami | Poprawka jako warunek zamknięcia |
| Krytyczna zależność od dostawcy bez alternatywy | Ujawnione ryzyko koncentracji; czasem kowenant |
| Bus factor jeden na kluczowym systemie | Pakiet retencyjny albo ubezpieczenie osoby kluczowej |
| Brak automatycznych wdrożeń | Wyceniony w planie po zamknięciu |
Co nie zasługuje na twoją uwagę
Audytorzy rozliczani od ustaleń wręczą ci długą listę. Większość nie ma znaczenia dla decyzji inwestycyjnej:
- Preferencje frameworka albo języka — każdy wybór ma krytyków
- Niespójny styl kodu i formatowanie
- Niski ogólny procent pokrycia testami, gdy ścieżki pieniędzy i auth są pokryte
- Przestarzałe zależności bez osiągalnej podatności
- Brak dokumentacji — naprawdę częsty, rzadko rozstrzygający, tani do naprawy
Jeśli raportu z audytu nie da się streścić komitetowi inwestycyjnemu w trzech zdaniach, został zakrojony jako ćwiczenie inżynierskie, a nie inwestycyjne.
Jak wygląda dobry rezultat
- Jednostronicowe streszczenie językiem biznesu, z jasną ogólną pozycją ryzyka
- Ustalenia uszeregowane konsekwencją, każde z dowodem, który zespół celu może zweryfikować
- Koszt naprawy w tygodniach inżynierskich, żeby przekładał się na pieniądze
- Rekomendowany 90-dniowy plan techniczny po zamknięciu
- Wyraźna lista tego, czego NIE badano, żeby nikt nie zakładał pokrycia, którego nie było
Określ zamawiane dowody
Kupujący powinien móc prześledzić ważne ustalenie do źródła i zrozumieć koszt reakcji.
- Wskaż repozytorium, commit, środowisko i datę przeglądu.
- Poproś o przykłady, dotknięte procesy i założenia nakładu pracy.
- Wymagaj listy wyłączeń i możliwości ponownego sprawdzenia.
Najczęstsze pytania
Ile trwa audyt kodu przed inwestycją?
Trzy do dziesięciu dni roboczych dla większości celów seed i Series A. Fintech, healthtech albo nietypowo duże bazy kodu trwają dłużej. Po dwóch tygodniach zwykle kupujesz szczegóły zamiast decyzji.
Czy startup będzie wiedział, że go audytujemy?
Tak — sensowny audyt wymaga dostępu do repozytorium i czasu inżynierów, więc to proces oparty na współpracy. Poważne cele tego oczekują i zwykle czują się z tym komfortowo; nietypowy opór sam w sobie wart jest odnotowania.
Czy da się audytować bez dostępu do kodu źródłowego?
Tylko powierzchownie. Bez repozytorium ocenisz działający produkt, publiczną postawę bezpieczeństwa i sygnały zespołowe, ale nie czystość IP, prawdziwą architekturę ani utrzymywalność — a to zwykle są ustalenia, które mają znaczenie.
Co, jeśli audyt znajdzie poważne problemy?
To udany audyt i rzadko kończy transakcję. Większość ustaleń zamienia się w budżet naprawczy, warunek zamknięcia, finansowanie w transzach albo korektę wyceny. Prawdziwa porażka to odkrycie tych samych problemów w szóstym miesiącu, gdy kosztują znacznie więcej.
Czy audytor potrzebuje kopii bazy produkcyjnej?
Nie domyślnie. Preferuj dane syntetyczne lub odpowiednio oczyszczone i ograniczony dostęp. Rozszerz go tylko dla konkretnego pytania bez mniej inwazyjnej alternatywy.
Potrzebujesz audytu przed przelewem?
Ustalenia uszeregowane konsekwencją biznesową, naprawa wyceniona w tygodniach inżynierskich, dostarczone w mniej niż dwa tygodnie.
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 techniczny MVP: co sprawdzamy w pierwszych 48 godzinach
Większość audytów MVP kończy się dokumentem. Użyteczny kończy się decyzjami: co się pali, co może poczekać i ile kosztuje naprawa.