Tech Due Diligence dla VC: co sprawdzam i dlaczego

Po 30+ procesach due diligence dla VC/PE najważniejszy wniosek jest prosty: większość DD ocenia to, co łatwo opisać, a nie to, co decyduje o dowożeniu po inwestycji.

Kod i stack można zmienić. Trudniej naprawić brak ownershipu, rozjazd CEO-CTO i kulturę „wszystko jest pilne". Dlatego mój framework kładzie nacisk na execution risk, nie tylko na technical debt.

Architektura i skalowalność systemu — czy system wytrzyma 10× ruch i czy koszty skalowania nie zjedzą marży. Jakość codebase i dług techniczny — ile sprint velocity blokuje istniejący kod i jak szybko rośnie ten dług. Proces release i przewidywalność delivery — jak często i jak przewidywalnie firma wypycha zmiany na produkcję. Ownership między product, engineering i data — kto finalnie decyduje co budujemy i czy ta osoba ma mandat.

Jakość roadmapy i spójność z KPI rundy — czy roadmapa wynikową z celów inwestycyjnych czy z życzeń zespołu. Proces discovery i decyzje produktowe — jak firma waliduje co budować zanim wyda pieniądze. Analityka i wiarygodność metryk — czy liczby w pitchdeck mają źródło w realnych systemach pomiarowych. Security, compliance i ryzyka operacyjne — szczególnie ważne przy sektorach regulowanych i danych osobowych.

Kompetencje liderów i struktura zespołu — czy team dowiezie plan inwestycyjny przy tym składzie i rytmie decyzji. Plan 30/60/90 i gotowość wdrożeniowa — czy spółka wie, co musi się zmienić żeby KPI rundy były realne.

Wynik DD to readiness score 10/10 + mapa ryzyk (krytyczne / umiarkowane / akceptowalne) + plan 30/60/90 z konkretnymi działaniami i ownerami. Nie raport do szuflady — działający plan, który mogę wdrożyć ze spółką po zamknięciu rundy.

Czas realizacji: 1–2 tygodnie. Format: remote lub on-site zależnie od preferencji funduszu i spółki.

Pre-investment to oczywistość, ale równie ważny jest post-investment triage i portfolio triage — kiedy KPI są czerwone i trzeba szybko ustalić, gdzie jest realne źródło problemu bez angażowania zarządu spółki na 2 tygodnie.