Fundusze VC i PE
Ocena ryzyka technologicznego i wykonawczego przed decyzją inwestycyjną lub jako triage dla spółki portfelowej z problemami.
Due Diligence & Risk
Tech Due Diligence
Oceniam ryzyko wykonawcze i gotowość spółki do realizacji planu inwestycyjnego. Nie tylko technologia — architektura, ownership, roadmapa, metryki i kompetencje zespołu.
✓Readiness score 10/10 z wagą ryzyk
✓Mapa ryzyk: krytyczne / umiarkowane / akceptowalne
✓Plan 30/60/90 z ownerami i terminami
Krótko
Tech Due Diligence to ocena ryzyka wykonawczego, nie tylko przegląd kodu. Obejmuje architekturę, jakość procesu wytwórczego, strukturę ownership, roadmapę, metryki i gotowość spółki do realizacji planu inwestycyjnego. Output to readiness score, mapa ryzyk i konkretny plan naprawy.
Kiedy potrzebny jest Tech DD
Tech Due Diligence jest potrzebny w kilku kluczowych momentach — nie tylko przed inwestycją:
- ⚠Spółka pokazuje trakcję w pitchdeck, ale delivery nie nadąża za planem rundy
- ⚠Inwestor ma wątpliwości co do skalowalności systemu lub roadmapy
- ⚠Founderzy nie są w stanie obronić decyzji technicznych podczas DD
- ⚠Metryki w prezentacji nie mają źródła w wiarygodnych systemach analitycznych
- ⚠Spółka portfelowa nie dowozi KPI po zamknięciu rundy
- ⚠Planowana akwizycja i potrzebujesz oceny ryzyka przed zamknięciem transakcji
Dla kogo
Aniołowie biznesu
Szybka ocena dojrzałości technicznej startupu przed inwestycją seed lub pre-seed.
Founderzy przygotowujący rundę
Proaktywny DD readiness — żeby wiedzieć co poprawi readiness score zanim inwestor zadaje pytania.
Nabywcy w transakcjach M&A
Ocena długu technicznego, ryzyk compliance i gotowości integracyjnej przed akwizycją.
10-punktowy framework
- →Architektura i skalowalność — czy system wytrzyma 10× ruch bez przepalenia marży
- →Jakość codebase i dług techniczny — ile velocity blokuje istniejący kod
- →Proces release i przewidywalność delivery — lead time od decyzji do produkcji
- →Ownership product–engineering–data — kto finalnie decyduje i czy ma mandat
- →Jakość roadmapy i spójność z KPI rundy — cel inwestycyjny vs lista życzeń
- →Proces discovery i decyzje produktowe — jak firma waliduje co budować
- →Analityka i wiarygodność metryk — czy pitch deck liczby mają źródło w danych
- →Security, compliance i ryzyka operacyjne — GDPR, SOC2, koncentracja dostępu
- →Kompetencje liderów i struktura zespołu — klucz-person risk, zdolność do skalowania
- →Plan 30/60/90 i gotowość wdrożeniowa — czy spółka wie co musi zmienić
Jak przebiega Tech DD
- 01
Kick-off i zakres
Ustalamy priorytety funduszu lub nabywcy, dostęp do dokumentacji i kluczowych osób. Definiujemy obszary podwyższonego ryzyka.
- 02
Przegląd dokumentacji
Analiza architektury, codebase, roadmapy, metryk, struktury zespołu i procesów. Bez zbędnego przeglądu wszystkiego — focus na ryzykach.
- 03
Wywiady techniczne
Rozmowy z CTO, tech leadami i PM-ami. Weryfikacja deklaracji z dokumentacją i metrykami.
- 04
Readiness score i mapa ryzyk
Ocena każdego z 10 punktów z wagą: krytyczne / umiarkowane / akceptowalne. Uzasadnienie każdej oceny.
- 05
Plan 30/60/90
Konkretne działania naprawcze z ownerami i terminami. Nie lista rekomendacji — plan, który można wdrożyć od pierwszego dnia po zamknięciu.
Co otrzymujesz
- ✓Readiness score — 10-punktowa ocena z wagą ryzyk i uzasadnieniem
- ✓Executive summary — 1-stronnicowe zestawienie kluczowych ryzyk dla investment committee
- ✓Szczegółowa mapa ryzyk — krytyczne / umiarkowane / akceptowalne z opisem
- ✓Red flags — lista blokerów wymagających działania przed lub po zamknięciu rundy
- ✓Plan 30/60/90 — działania z ownerami, terminami i metrykami sukcesu
- ✓Opcjonalnie: call z IC lub zarządem spółki — Q&A na podstawie raportu
Red flags, które identyfikujemy
Brak jednego ownera decyzji product-tech — wszyscy decydują, nikt nie odpowiadaRoadmapa oderwana od tezy inwestycyjnej lub KPI rundySkalowanie wyłącznie przez więcej ludzi lub infrastrukturyDług techniczny ukryty jako "zrobimy refactoring później"Brak wiarygodnego źródła prawdy dla metryk z pitch deckaRelease zależny od jednej osoby — koncentracja ryzykaSecurity i compliance odłożone na "po wzroście"
Tech DD vs Code Review vs Audyt techniczny
| Kryterium | Tech Due Diligence | Code Review |
|---|---|---|
| Zakres | Architektura, proces, ludzie, metryki, roadmapa | Tylko kod |
| Cel | Ocena ryzyka wykonawczego i inwestycyjnego | Ocena jakości codebase |
| Output | Readiness score + mapa ryzyk + plan 30/60/90 | Lista issues i rekomendacji |
| Czas | 1–2 tygodnie | 2–5 dni |
| Dla kogo | VC, PE, nabywcy, founderzy pre-runda | Engineering teams, CTOs |
Najczęstsze pytania
Czym jest Tech Due Diligence?
Tech DD to ocena ryzyka wykonawczego spółki — nie tylko jakości kodu, ale architektury, procesu delivery, jakości decyzji produktowych, struktury zespołu i gotowości do realizacji planu inwestycyjnego.
Czy Tech DD dotyczy tylko kodu?
Nie. Kod to jeden z 10 punktów. Równie ważne są: proces release, ownership decyzji, roadmapa, wiarygodność metryk, security i zdolność zespołu do dowiezienia planu po inwestycji.
Ile trwa Tech Due Diligence?
Standardowy proces: 1–2 tygodnie od kick-off do dostarczenia raportu. Przy ograniczonym dostępie do danych lub poszerzonym zakresie — do 3 tygodni. Szybszy triage możliwy w 3–5 dni dla inwestorów z pilnym terminem.
Jaki jest output?
Readiness score 10/10, executive summary, szczegółowa mapa ryzyk i plan 30/60/90. Format: dokument + opcjonalny call z investment committee lub zarządem spółki.
Kiedy fundusz powinien uruchomić Tech DD?
Możliwie wcześnie w procesie inwestycyjnym — zanim wejdziesz w intensywne negocjacje. Wczesny DD pozwala negocjować na faktach, nie na poczuciu ryzyka. Dla spółek portfelowych — przy pierwszych sygnałach problemów z KPI.
Czy Tech DD może zaszkodzić relacji z founderami?
Dobry DD buduje zaufanie — founderzy wiedzą, że inwestor rozumie ich technologię i procesy. Problematyczny jest DD prowadzony jako przesłuchanie, nie jako wspólna ocena ryzyka. Moje podejście: partnerskie, konkretne, bez szukania winnych.
Powiązane usługi
Fractional Leadership
Fractional CTO / CPO
Wchodzę w rytm firmy i przejmuję odpowiedzialność za decyzje product-tech na poziomie C-level — bez pełnoetatowego kosztu i bez warstwy doradczej, która kończy się na slajdach.
Czytaj więcej →Engineering Leadership
VP of Engineering / Head of Engineering
Wchodzę jako interim lub fractional VP Engineering gdy engineering traci velocity: sprinty nie domykają się, release cycle rośnie, seniorzy są przeciążeni zarządzaniem. Przywracam rytm delivery i system ownershipu.
Czytaj więcej →AI & Strategy
Wdrożenia AI w organizacji
Prowadzę organizację przez cały cykl adopcji AI: od audytu gotowości, przez wybór procesów i pilota, aż do produkcyjnego wdrożenia i governance. Bez chaosu eksperymentów i bez projektów szuflady.
Czytaj więcej →Growth & Execution
Optymalizacja KPI i growth
Diagnozuję, gdzie firma traci konwersję, retencję i throughput — i buduję system eksperymentów, który przekłada się na KPI, nie na listę zamkniętych tasków.
Czytaj więcej →