Checklista jest użyteczna tylko wtedy, gdy do każdej pozycji przypięta jest konsekwencja. Ta jest uporządkowana według tego, co naprawdę zmienia transakcję.
Własność i zależności
Produkt i operacje
Naprawa i decyzja
Używaj tego jako dokumentu roboczego w trakcie badania. Każda sekcja mówi, o co prosić, co zweryfikować i — co kluczowe — co zła odpowiedź oznacza komercyjnie. Pozycje ułożone są według kosztu pomyłki, a nie wygody sprawdzania.
Zanim zaczniesz: o co prosić
- Dostęp do odczytu wszystkich repozytoriów, łącznie z infrastructure-as-code
- Pełna historia commitów (nie spłaszczony zrzut — historia pokazuje, kto to naprawdę zbudował i jak szybko)
- Omówienie architektury z inżynierem, który ją zbudował, 1-2 godziny
- Dostęp do systemu zgłoszeń i wszelkich zapisów incydentów
- Lista usług zewnętrznych i ich warunków umownych
- Umowy z kontraktorami i dokumenty przeniesienia IP
Sekcja 1 — Integralność pieniędzy i danych (poziom transakcji)
| Kontrola | Zła odpowiedź oznacza |
|---|---|
| Salda wyprowadzane z księgi append-only? | Pieniądze mogą być po cichu błędne i nieodwracalne — sfinansuj naprawę albo odejdź |
| Klucze idempotencji na każdej ścieżce płatności? | Ponowienia mogą obciążyć dwa razy; straty mogą już istnieć niewykryte |
| Pieniądze jako liczby całkowite w jednostkach podrzędnych? | Arytmetyka zmiennoprzecinkowa kumuluje błąd przy każdej transakcji |
| Rekoncyliacja wobec rozliczeń dostawcy? | Rozbieżności wychodzą przez reklamacje klientów |
| Niezmienny ślad audytowy wraz z działaniami admina? | Nie da się odpowiedzieć regulatorowi ani w sporze |
Sekcja 2 — Bezpieczeństwo i wielonajemność (poziom transakcji)
- Autoryzacja egzekwowana po stronie serwera przy każdym żądaniu, a nie przez chowanie elementów interfejsu
- Izolacja najemców zweryfikowana testem, a nie założona po lekturze kodu
- Sekrety w menedżerze, nieobecne w historii gita (sprawdź historię, nie tylko HEAD)
- Jakie dane regulowane są przechowywane, gdzie i czy to konieczne
- Dystans do certyfikacji wymaganej przez go-to-market (SOC 2, ISO 27001, PCI DSS)
Sekcja 3 — Własność i kwestie prawne (poziom transakcji)
- Podpisane przeniesienie IP od każdego kontraktora i założyciela
- Przegląd licencji open source — skażenie copyleft w produkcie zamkniętym
- Kod skopiowany od poprzednich pracodawców (zapytaj wprost; to się zdarza)
- Uzależnienie od dostawcy: co pęknie, jeśli kluczowy dostawca zmieni ceny albo zniknie
Sekcja 4 — Architektura i skala (wysokie)
- Gdzie system pęka przy wzroście z modelu finansowego — konkretna liczba, a nie zapewnienia
- Sufit warstwy danych: pojedynczy master do zapisu, nieograniczone zapytania, pokrycie indeksami wobec rzeczywistych wzorców
- Izolacja awarii: czy jedna wolna zależność przeradza się w pełną awarię
- Krzywa kosztów infrastruktury przy 10× — czy unit economics przetrwa
- Architektura dopasowana do wielkości zespołu (systemy rozproszone przy małym zespole to koszt, a nie tytuł do chwały)
Sekcja 5 — Zdolność dostarczania (wysokie)
| Sygnał | Zdrowo | Niepokojąco |
|---|---|---|
| Częstotliwość wdrożeń | Kilka razy w tygodniu | Miesięcznie, planowo, ze strachem |
| Czas dostarczenia małej zmiany | Godziny do jednego dnia | Tygodnie |
| Rollback | Jedna komenda, przećwiczona | Nigdy nietestowany |
| Wykrywanie incydentów | Monitoring wewnętrzny | Zgłoszenia klientów |
| Testy na ścieżkach pieniędzy/auth | Obecne | Nieobecne niezależnie od ogólnego pokrycia |
Sekcja 6 — Zespół i ryzyko osoby kluczowej (wysokie)
- Bus factor każdego krytycznego podsystemu — jeśli gdziekolwiek wynosi 1, to ryzyko transakcyjne wymagające zabezpieczenia
- Czy wiedza istnieje na piśmie, czy tylko w głowach
- Ekspozycja retencyjna: czyja utrata w ciągu 12 miesięcy byłaby katastrofą
- Realizm planu rekrutacji zakładanego przez roadmapę
Punktacja: konsekwencja, a nie gust
Oceniaj każde ustalenie po tym, co się stanie, jeśli nie zostanie naprawione, i niech to steruje reakcją w transakcji:
- Poziom transakcji — integralność pieniędzy, wyciek danych, niejasne IP. Warunek zamknięcia albo sfinansowana naprawa.
- Wysokie — sufit skalowania poniżej planu, zależność od jednej osoby, brak bezpieczeństwa wdrożeń. Wycenione w 90-dniowym planie po zamknięciu.
- Średnie — kumulujący się dług spowalniający dostarczanie. Odnotować i monitorować.
- Szum — styl, preferencje frameworka, objętość dokumentacji. Całkowicie wyłączyć z raportu.
Jeśli ustalenia nie da się powiązać z pieniędzmi, czasem albo ekspozycją prawną, nie ma go po co umieszczać w memorandum inwestycyjnym.
Czego wymagać w raporcie końcowym
- Jednostronicowe streszczenie, na podstawie którego może działać nietechniczny partner
- Każde ustalenie z dowodem, który zespół celu może samodzielnie zweryfikować
- Wyceny naprawy w tygodniach inżynierskich, żeby przekładały się na pieniądze
- Wyraźne stwierdzenie, czego NIE badano — żeby nikt nie zakładał pokrycia, którego nie było
Zamień checklistę w podstawę decyzji
Każda odpowiedź wymaga dowodów i związku z transakcją. Uzgodnij granice, dostępy i pytania przed zbieraniem dokumentów. Oddziel ustalenia, deklaracje zarządu i brakujące materiały. Pusta komórka nie dowodzi niskiego ryzyka.
| Podejmij mierzalną decyzję | Ustal dowody przed rozpoczęciem |
|---|---|
| Własność i zależności | Poproś o historię repozytorium, umowy współpracowników i listę zależności. Prawa weryfikuje doradca prawny. |
| Produkt i operacje | Przejdź istotną ścieżkę, sprawdź wdrożenie i odtwarzanie, porównaj architekturę z założeniami wzrostu. |
| Naprawa i decyzja | Przypisz właściciela, wysiłek, zależności i weryfikację. Oddziel warunki przed transakcją od planu po niej. |
Raport wskazuje zakres badania, niewiadome i konsekwencje. Sama analiza dokumentów nie potwierdza skuteczności kontroli produkcyjnych; przegląd techniczny nie jest certyfikacją prawną.
Najczęstsze pytania
Co powinna zawierać checklista technicznego due diligence?
Sześć obszarów w kolejności konsekwencji: integralność pieniędzy i danych, bezpieczeństwo i izolacja najemców, własność IP, architektura i zapas na skalowanie, zdolność dostarczania oraz ryzyko osoby kluczowej. Każda pozycja powinna mieć określoną konsekwencję komercyjną — checklista bez konsekwencji produkuje raporty, na podstawie których nikt nie działa.
Który punkt jest najczęściej pomijany?
Przeniesienie IP od kontraktorów. To nie jest pytanie techniczne, więc recenzenci techniczni je pomijają, a prawnicy zakładają, że zajęła się tym inżynieria. Ma też najdłuższy czas naprawy, dlatego należy je sprawdzać w pierwszych dniach, a nie w ostatnich.
Czy założyciele mogą sami użyć tej checklisty?
Tak i przed rundą to dobry pomysł. Ustalenia, które odkryjesz sam, stają się planem naprawczym, który kontrolujesz; te same ustalenia odkryte przez doradcę inwestora stają się pozycją negocjacyjną przeciw tobie.
Chcesz, żeby zrobił to ktoś, kto robi to co tydzień?
Dostarczamy diligence z ustaleniami uszeregowanymi konsekwencją biznesową i naprawą wycenioną w tygodniach inżynierskich.
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?
Czego naprawdę szukają VC w technicznym due diligence
Inwestorzy nie oceniają twojego kodu. Wyceniają ryzyko, że technologia zatrzyma plan, który finansują — a założyciele, którzy to rozumieją, przygotowują się zupełnie inaczej.