Jak przygotować startup do rundy od strony technicznej — checklist i plan 60 dni

Tech due diligence to jeden z etapów który founderzy przygotowują najgorzej. Financials są gotowe, traction deck jest dopieszczony, pitchdeck przeszedł przez 10 iteracji — ale kiedy inwestor pyta o architekturę systemu, roadmapę techniczną albo metryki delivery, odpowiedź jest improwizowana.

Ten artykuł to konkretny plan: co przygotować, w jakiej kolejności i dlaczego te a nie inne rzeczy mają wpływ na wycenę.

Po 30+ procesach DD w Polsce i Europie widzę spójny wzorzec. Inwestor nie szuka perfekcji — szuka sygnałów ryzyka i sygnałów dojrzałości.

Sygnały ryzyka które obniżają wycenę lub blokują deal: architektura która nie skaluje się bez przepisania; brak observability (nie wiesz kiedy system jest down, nie masz alertów, nie masz metryk); kluczowe kompetencje tylko w jednej osobie (bus factor = 1); dług techniczny bez świadomości i planu; metryki "opowiedziane" nie zmierzone.

Sygnały dojrzałości które zwiększają wycenę: jasna architektura z dokumentacją decyzji; mierzalne KPI delivery (cycle time, error rate, uptime SLA); roadmapa techniczna spójna z biznesową; kompetentny tech lead który może rozmawiać z DD bez foundera w pokoju.

Dni 1–15: Audyt i lista. Architektura: narysuj aktualny diagram, zidentyfikuj single points of failure, oceń gdzie architektura nie skaluje się przy 10× ruchu. Dług techniczny: zrób listę znanych długów z szacunkowym kosztem spłaty. Metryki: sprawdź czy masz baseline dla kluczowych metryk. Zespół: oceń bus factor.

Dni 16–35: Naprawy priorytetowe. Skup się na sprawach które DD odkryje jako czerwone flagi: (1) Observability — jeśli nie masz alertów i dashboardu uptime, wdrożenie zajmuje 1–2 tygodnie. (2) Bus factor — sparuj wiedzę. (3) Dług blokujący skalowanie. (4) Metryki — upewnij się że możesz pokazać dashboard który sami sprawdzacie.

Dni 36–50: Dokumentacja. W data room sekcja techniczna powinna mieć: diagram architektury (aktualny), lista stack technologicznego z uzasadnieniem, lista znanych długów z priorytetyzacją i planem, roadmapa techniczna na 12 miesięcy, metryki delivery (cycle time trend, error rate, uptime), schemat organizacyjny z rolami i ownership.

Dni 51–60: Rehearsal. Przeprowadź mock DD z kimś zewnętrznym. Typowe pytania: jak wygląda typowy release; co by się stało gdyby kluczowy inżynier odszedł jutro; jakie są największe ryzyka techniczne na następne 18 miesięcy; jak walidujecie że metryki które pokazujecie są prawdziwe.

"Nie mamy API do kluczowego systemu." Trudno opowiedzieć jak się skaluje system którego nie możesz instrumentować. Minimum: health check endpoint, basic metrics.

"Metryki retention wyszły inaczej w różnych narzędziach." To jest alarm dla inwestora. Zanim DD — upewnij się że definicje są spójne.

"Roadmapa techniczna istnieje tylko w głowie CTO." Każdy deck musi mieć pisemną roadmapę, nawet uproszczoną. Brak dokumentacji to sygnał braku dojrzałości operacyjnej.

"Cały team jest w jednym biurze i jeden inżynier to 60% commitów." Koncentracja ryzyka. Nie musisz tego rozwiązać przed DD, ale musisz mieć plan.

Jak długo przed rundą zaangażować wsparcie techniczne? Minimum 6–8 tygodni. Przy złożonym stacku lub dużym długu technicznym — 12 tygodni. Zaangażowanie Fractional CTO na 4–6 tygodniowy sprint przed DD to jeden z najlepszych ROI przed rundą.

Czy inwestor zawsze robi pełny tech DD? Seed i pre-seed: często nie ma formalnego DD, ale inwestor robi informal assessment w rozmowie. Series A i wyżej: zawsze jest formalny DD, często z zewnętrznym CTO lub firmą DD.

Co jeśli DD odkryje poważny problem? Lepiej go znaleźć i zaadresować przed DD niż w trakcie. Problem znaleziony w DD to czerwona flaga. Problem znaleziony przez was + plan naprawy to sygnał dojrzałości.

Czy dług techniczny automatycznie obniża wycenę? Nie — świadomość długu i plan zarządzania nim jest wystarczający dla większości inwestorów. Obniżają wycenę: nieświadomość długu, dług blokujący skalowanie, brak planu.