Technical due diligence przed rundą: co sprawdzi fundusz VC

Techniczne due diligence to nie egzamin, który się zdaje albo oblewa. Fundusz szuka ryzyk podważających obietnicę wzrostu z Twojego pitch decku i szacuje koszt ich usunięcia. Słaby wynik sam w sobie rzadko przekreśla transakcję, ale potrafi odebrać Ci argumenty przy negocjowaniu wyceny. Dlatego zamiast polerować kod pod audyt, poznaj te ryzyka wcześniej niż fundusz i przygotuj plan ich ograniczenia.

Kto zleca techniczne due diligence: fundusz VC, nie anioł

Szczegółowy przegląd technologii to przede wszystkim narzędzie instytucjonalnego funduszu VC. Fundusz inwestuje cudze pieniądze i z podjętego ryzyka rozlicza się przed swoimi inwestorami. Osoba inwestująca własne oszczędności odpowiada wyłącznie przed sobą, więc rzadko zamawia i finansuje pełny audyt.

Anioł biznesu może poprosić zaufanego programistę o krótką rozmowę z zespołem, obejrzeć demo albo zadać pytania o architekturę. Nie jest to jednak ten sam proces co formalny audyt kodu, infrastruktury, zespołu i dokumentacji.

Na etapie seed produkt bywa zbyt młody, aby obecny kod mówił wiele o przyszłej spółce. Leo Polovets, inwestor VC i były inżynier, wskazuje, że głębokie tech DD na tym etapie często marnuje czas obu stron. Większego znaczenia nabiera zwykle od Series A, kiedy fundusz finansuje już nie tylko eksperyment, lecz także obietnicę szybkiego wzrostu.

Tech DD może pojawić się również w kolejnej rundzie, zwłaszcza gdy do spółki wchodzi duży, nowy fundusz. Dotychczasowi inwestorzy znają firmę lepiej i mogą podejść do przeglądu inaczej, ale nie warto zakładać, że kolejna runda automatycznie odbędzie się bez audytu.

Nie istnieje też jedna uniwersalna checklista. Fundusz sprawdzi inne ryzyka, gdy kapitał ma sfinansować dziesięciokrotny wzrost liczby użytkowników, a inne przed wejściem na regulowany rynek. Standardowa lista dokumentów potrzebnych przy rundzie VC obejmuje między innymi sprawy korporacyjne i własność intelektualną. Szczegółowy przegląd technologii jest osobnym obszarem, który fundusz uruchamia, gdy uzna go za istotny.

Jak słabe tech DD obniża wycenę rundy

Tech DD nie jest pierwszym etapem selekcji, tylko potwierdzeniem decyzji podjętej wcześniej. Na tym etapie fundusz zna już Twój produkt, rynek i zespół. Zwykle rozmawiacie też o wstępnych założeniach inwestycji. Nadal może jednak zmienić warunki, jeśli audyt ujawni koszt, którego nie uwzględnił w swoich wyliczeniach.

Załóżmy, że pitch deck obiecuje szybkie wejście na trzy nowe rynki. Audyt pokazuje tymczasem, że system nie potrafi przechowywać danych klientów w wymaganym przez lokalne przepisy kraju, każda integracja wymaga zmian w wielu modułach, a wiedzę o infrastrukturze ma jedna osoba. Fundusz przelicza to na dodatkowe miesiące pracy, nowe rekrutacje i budżet, który zamiast na sprzedaż pójdzie na przebudowę systemu.

Najczęstszy rezultat nie brzmi więc: „kończymy rozmowy”. Bardziej prawdopodobny jest plan naprawczy, dodatkowy warunek zamknięcia transakcji albo argument za niższą wyceną. Fundusz może też uwzględnić koszt usunięcia problemów w planie wykorzystania kapitału.

Nikt nie poda Ci wiarygodnego procentu, o jaki spada w takiej sytuacji wycena. Skala obniżki zależy od tego, jak bardzo ryzyko zagraża celowi rundy, ile kosztuje jego usunięcie i kto ma silniejszą pozycję w negocjacjach. Problem, który nie wpływa na wzrost przez najbliższe dwa lata, znaczy mniej niż architektura blokująca główną obietnicę z pitch decku.

Słaby wynik może przesądzić o rezygnacji, jeśli fundusz już wcześniej miał poważne wątpliwości biznesowe albo odkryje, że spółka zataiła istotne ryzyko. To jednak skrajny scenariusz. W drugą stronę działa to jeszcze słabiej: wzorowe repozytorium nie zrekompensuje braku rynku, wzrostu sprzedaży czy sensownej ekonomiki produktu.

Nie przygotowujesz się zatem po premię za doskonałość inżynierską. Chronisz wycenę i pozycję w negocjacjach przed kosztami, które audyt i tak wykaże.

Co fundusz sprawdzi poza jakością kodu

Audytor nie szuka perfekcji. Szuka ryzyk, których founder nie zna, nie potrafi wycenić albo nie umie powiązać z planem finansowanym przez rundę.

Samą jakość kodu można zmierzyć narzędziami i Twój zespół może to zrobić na własną rękę, zanim ktokolwiek poprosi o dostęp do repozytorium. Trudniejsze pytania zaczynają się tam, gdzie stan techniczny trzeba przełożyć na czas, pieniądze i ryzyko dla planów spółki. Poniższe pięć obszarów wraca w takich rozmowach najczęściej.

Dług technologiczny bez planu to nie backlog bugów

Dług technologiczny nie jest sam w sobie sygnałem alarmowym. Każdy zespół świadomie wybiera czasem szybsze rozwiązanie, aby sprawdzić hipotezę lub dowieźć ważną funkcję.

Problem zaczyna się wtedy, gdy nikt nie wie, gdzie zaciągnięto ten dług, dlaczego powstał i kiedy zacznie blokować rozwój. Odpowiedź „naprawiamy błędy na bieżąco w sprintach” nie pokazuje kontroli, bo bugi i dług technologiczny nie są tym samym.

Wiarygodny zespół potrafi wskazać konkretne obszary, konsekwencje kompromisów i przybliżony plan spłaty. Nie musi obiecywać systemu bez długu. Powinien umieć powiedzieć, które ryzyko wymaga czterech sprintów pracy, które można świadomie zaakceptować, a które zagrozi celowi rundy.

Architektura i ADR: kto podjął decyzję

Brak dokumentacji zostanie odnotowany jako luka wymagająca wyjaśnienia lub działania. Audytor chce zobaczyć nie tylko obecną architekturę, lecz także tok rozumowania stojący za kluczowymi decyzjami.

Pomagają w tym aktualne diagramy C4 oraz ADR-y (Architecture Decision Records), czyli krótkie zapisy decyzji architektonicznych, ich kontekstu i konsekwencji. Dzięki nim można ustalić, dlaczego zespół wybrał daną bazę, podzielił system w określony sposób albo zaakceptował konkretną zależność.

W tym obszarze pojawią się też podstawowe pytania o bezpieczeństwo infrastruktury: dostęp, zarządzanie sekretami, elementy dostępne z internetu i znane podatności. Nie oznacza to automatycznie pełnego pentestu czy audytu zgodności. Fundusz chce jednak wiedzieć, czy podstawowa higiena bezpieczeństwa odpowiada ryzyku produktu.

Czy system udźwignie wzrost obiecany inwestorom

Skalowalność liczy się tylko w odniesieniu do planu biznesowego. System nie musi dziś obsługiwać stukrotnie większego ruchu, ale zespół powinien wiedzieć, co trzeba zmienić, ile to potrwa i jak wpłynie na koszty.

Audytor porówna obietnicę z decku z architekturą i infrastrukturą. Sprawdzi, czy wzrost liczby klientów wymaga dokładania zasobów w podobnym tempie, czy powoduje nieproporcjonalny skok kosztów. Zapyta też, czy od razu można rosnąć, czy najpierw trzeba zatrzymać rozwój produktu i przez kilka miesięcy przebudowywać jego fundamenty.

Bus factor: ilu ludzi musiałoby odejść, żeby produkt stanął

Fundusz inwestuje również w zdolność zespołu do utrzymania i rozwijania systemu. Jeśli urlop jednego inżyniera zatrzymuje wdrożenia, produkt nie jest gotowy na wzrost. Dzieje się tak nawet wtedy, gdy kod działa bez zarzutu.

To ryzyko opisuje bus factor: liczba osób, których odejście pozbawiłoby zespół krytycznej wiedzy. Audytor może sprawdzić, kto zna najważniejsze części systemu i kto potrafi odtworzyć infrastrukturę.

Nie chodzi o to, aby każda osoba znała cały system. Chodzi o wskazanie miejsc zależnych od jednego „rockstara” oraz plan przekazania wiedzy lub rekrutacji brakujących kompetencji.

Licencje open source, IP i vendor lock-in

Zewnętrzna biblioteka albo usługa może ukrywać koszt większy niż dług techniczny we własnym kodzie. Dlatego fundusz sprawdzi, z jakich zewnętrznych bibliotek i usług korzysta produkt, czy są aktualizowane, na jakich licencjach działają i czy dałoby się zastąpić tych najważniejszych dostawców.

Licencja copyleft, w tym AGPL, użyta w produkcie SaaS może wiązać się z obowiązkami prawnymi. To inny problem niż przestarzały pakiet. Osobno trzeba potwierdzić, czy spółka ma prawa do kodu stworzonego przez founderów, pracowników i kontraktorów. Dokumentacja due diligence VC wymienia przeniesienie praw własności intelektualnej i licencje jako stały obszar kontroli prawnej.

Ryzyko vendor lock-in rośnie z kolei wtedy, gdy kluczowa funkcja zależy od jednego dostawcy, a jego integracja jest rozlana po całym systemie. Awaria, podwyżka ceny lub nowe wymagania zgodności mogą wtedy wymusić kosztowne przepisywanie produktu. Zewnętrzny SaaS staje się groźny, gdy uzależnienia od dostawcy nikt nie zauważył ani nie wycenił.

Jak przygotować zespół i dokumentację przed rundą

Twoim zadaniem jest zlecić przygotowanie materiałów i dopilnować, żeby zespół zestawił stan technologii z celem rundy. Poniższe pięć kroków możesz uruchomić od razu.

1. Nazwij cele biznesowe zależne od systemu. Określ, czy runda ma sfinansować stukrotny wzrost, nowy kanał sprzedaży, wejście na kolejny rynek czy obsługę dużych klientów.
2. Skonfrontuj cele z zespołem. Przedstaw plan i zapytaj wprost, co w technologii, procesie oraz kompetencjach może stanąć na przeszkodzie. Nie pytaj tylko, czy „damy radę”.
3. Zleć aktualizację dokumentacji. Potrzebujesz obrazu obecnego systemu, na przykład diagramów C4, oraz listy najważniejszych ADR-ów. Slajd z docelową architekturą nie zastępuje opisu stanu faktycznego. Jeśli produkt rozwija dla Ciebie zewnętrzny software house, sprawdź, jakiej dokumentacji wymagać od dostawcy.
4. Sprawdź zależności i licencje. Zespół powinien znać wersje bibliotek i frameworków, ich licencje oraz osobę odpowiedzialną za aktualizacje.
5. Połącz infrastrukturę z ekonomią wzrostu. Poproś o aktualny diagram infrastruktury i prognozę kosztów dla celu z pierwszego punktu. Sama obecna faktura za chmurę niewiele mówi.

Te prace może wykonać Twój zespół. Nie potrzebujesz zewnętrznej firmy, aby zacząć. Jeśli odpowiedzi są niepełne, nie maskuj braków przed funduszem. Ustal właścicieli, oszacuj koszt i pokaż kolejność działań. Znane ryzyko z rozsądnym planem jest łatwiejsze do obrony niż niespodzianka odkryta przez audytora.

Oceń stan techniczny produktu, zanim sięgniesz po wsparcie

Najpierw sprawdź samą warstwę techniczną. Po wsparcie z zewnątrz sięgnij wtedy, gdy w firmie brakuje osoby, która połączy wyniki przeglądu z kosztem, ryzykiem i planem rundy.

Możesz zacząć od bezpłatnej checklisty stanu technicznego produktu. Obejmuje ona między innymi architekturę, testy, CI/CD, obserwowalność, dane i bezpieczeństwo. Przejdź ją z zespołem, zanim zrobi to za Was audytor funduszu. Wtedy przynajmniej będziecie wiedzieć, co znajdzie.

Jeśli luki są już nazwane, ale nikt w firmie nie potrafi ustalić kolejności napraw ani powiedzieć, ile każda z nich kosztuje i co da przed rundą, rozważ wspieranie projektów technologicznych. Doświadczony Tech Lead albo Interim CTO poukłada te luki według wpływu na cel rundy, pokaże koszt i czas naprawy każdej z nich i powie wprost, które warto zamknąć przed rozmowami z funduszem, a które spokojnie mogą poczekać.

Podsumowanie

Fundusz nie ocenia czystości Twojego repozytorium. Sprawdza, ile naprawdę będzie kosztowało dowiezienie wzrostu, który obiecujesz w pitch decku, i czy znasz już ten koszt.

Najwięcej kosztuje Cię więc nie długa lista uwag z audytu, lecz ryzyko, o którym fundusz dowiaduje się pierwszy i którego nikt w spółce nie potrafi wycenić. Wtedy tracisz wiarygodność i pole do negocjacji. Zidentyfikuj te ryzyka wcześniej, zestaw je z celem rundy i zdecyduj, które ograniczyć przed rozmowami, a które świadomie zaakceptować.