Czy przejdziesz techniczne due diligence?

Checklista technicznego due diligence, z której naprawdę korzystają inwestorzy

Każde techniczne due diligence, które przeprowadzam — podobnie jak powyższa checklista — sprowadza się do ośmiu wymiarów. To w nich kryją się kosztowne niespodzianki i to na nie inwestorzy kładą największy nacisk podczas badania:

• Bezpieczeństwo — sekrety trzymane poza repozytorium, skanowane i aktualizowane zależności, dostęp do środowiska produkcyjnego z minimalnymi uprawnieniami oraz niezależny audyt kodu.
• Własność intelektualna i własność kodu — kompletne, pisemne przeniesienie praw autorskich od każdej osoby pracującej przy kodzie, zarówno pracowników, jak i kontraktorów, bez nierozstrzygniętych roszczeń osób trzecich.
• Architektura i skalowalność — czy architektura wytrzyma 10-krotnie większe obciążenie i czy pojedynczy punkt awarii (SPOF) może unieruchomić cały produkt.
• Bus factor (ryzyko kluczowej osoby) — jaka część wiedzy o systemie istnieje tylko w głowie jednej osoby i czy dokumentacja pozwala nowemu członkowi zespołu na jego obsługę.
• DevOps / dostarczanie (metryki DORA) — częstotliwość wdrożeń, czas realizacji zmian, wskaźnik nieudanych zmian i czas przywrócenia usługi: czyli jak zespół faktycznie dostarcza oprogramowanie.
• Dług techniczny — ile czasu poświęca się na gaszenie pożarów zamiast na rozwój oraz jakie migracje lub projekty przepisania kodu obciążają roadmapę.
• Pokrycie testami i bramkowanie w CI — czy istnieją wartościowe testy i czy faktycznie blokują wydanie w przypadku niepowodzenia.
• Licencjonowanie open-source — brak licencji copyleft w kluczowych częściach produktu oraz lista komponentów oprogramowania (SBOM), aby skanowanie licencji nie przyniosło niespodzianek.

Jak pomyślnie przejść techniczne due diligence

Aby pomyślnie przejść techniczne due diligence, wyeliminuj czynniki blokujące transakcję, zanim otworzysz data room. To czerwone flagi, które nie obniżają ceny, lecz uniemożliwiają zawarcie umowy:

• Uzyskaj kompletne, pisemne przeniesienie praw własności intelektualnej od każdej osoby, która kiedykolwiek pracowała przy kodzie, włączając w to kontraktorów.
• Przed rozpoczęciem badania rozstrzygnij na piśmie wszelkie nierozwiązane roszczenia osób trzecich dotyczące kodu.
• Przenieś klucze i dane poufne z repozytorium do zarządzanego sejfu i zmień te, które wyciekły.
• Wymień lub zmień licencję każdego komponentu copyleft w kluczowym produkcie.
• Zlikwiduj zależność od jednej osoby: udokumentuj krytyczne systemy i wdróż drugą odpowiedzialną osobę.

Następnie zadbaj o czytelność pozostałych elementów — stwórz listę komponentów oprogramowania (SBOM), testy na ścieżkach krytycznych zintegrowane z CI, redundantną architekturę i plan spłaty długu technicznego powiązany z roadmapą — aby pokazać, że zespół panuje nad własnym systemem. Czerwone flagi zidentyfikowane w tym teście to dokładnie te kwestie, które zweryfikuje prawdziwe techniczne due diligence inwestora.

Od bezpłatnej weryfikacji do audytu Pre-DD

Ta bezpłatna weryfikacja ma charakter orientacyjny i bazuje na autodeklaracji. Jeśli potrzebujesz zweryfikowanej oceny — takiej, której zaufa inwestor — kolejnym krokiem jest Audyt Pre-DD: przeprowadzana dla founderów próba generalna audytu, który realizuję dla inwestorów, o z góry określonym zakresie. Obejmuje te same osiem wymiarów, opiera się na dowodach, a nie na samoocenie, pozwala zidentyfikować problemy do naprawy i przygotować Twój data room — tak aby proces due diligence przyspieszył rundę finansowania, zamiast ją blokować. Jest to część mojej usługi Investor Readiness — usługi, która przygotowuje Cię do pomyślnego przejścia technicznego due diligence.