Due diligence technologiczne: na co inwestor patrzy w kodzie i architekturze

Intencja inwestora technologicznego a oczekiwania wobec startupu

Założyciel szuka kapitału, inwestor szuka przewidywalności. Due diligence technologiczne to dla niego narzędzie, które ma odpowiedzieć na jedno pytanie: czy ten produkt da się bezpiecznie i sensownie dowieźć do skali, o której mówi pitch deck. Jeśli nie, oczekiwana wycena jest z góry zawyżona, a ryzyko – nieakceptowalne.

Audyt technologiczny startupu nie jest „pogłaskaniem kodu”. To próba oceny, ile faktycznie warte jest to, co już zostało zbudowane: kod, architektura systemu, procesy w zespole, bezpieczeństwo i compliance w SaaS, a nawet kultura techniczna. Każdy fragment znanego długu technologicznego, każdy brak testów i każdy chaos w repozytorium zwiększa ryzyko, że produkt nie dowiezie obiecanego wzrostu.

Jeśli założyciel rozumie due diligence technologiczne jako kluczowy etap wyceny i budowy zaufania, ma szansę przygotować się tak, by audyt pokazał dojrzałość, a nie tylko problemy. Jeśli traktuje to jako przykrą formalność, szybko wyjdzie na jaw, że technologia stoi na glinianych nogach.

Czym jest due diligence technologiczne z perspektywy inwestora

Różnica między due diligence technologicznym a zwykłym code review

Due diligence technologiczne to znacznie więcej niż klasyczne code review. Code review skupia się na jakości konkretnego fragmentu kodu: czytelności, błędach, zgodności ze standardem. Audyt technologiczny startupu obejmuje pełny kontekst: od repozytorium, przez architekturę, aż po proces release’ów i sposób pracy zespołu.

Inwestor nie interesuje się pojedynczym złym ifem, tylko wzorcem chaosu. Patrzy, czy w due diligence kodu źródłowego widać powtarzalne problemy: brak testów, brak standardów, brak przemyślanych granic między modułami. Jeden plik z bałaganem jest wypadkiem; bałagan rozmnożony w całym projekcie to sygnał ostrzegawczy.

Code review da się zrobić „na szybko” w kilka godzin. Pełne due diligence technologiczne, szczególnie przy większej bazie kodu i kilku usługach, wymaga zaplanowanego procesu i czasu na analizę architektury systemu, infrastruktury i praktyk operacyjnych.

Czego inwestor szuka w due diligence technologicznym

Perspektywa inwestora jest wyjątkowo pragmatyczna. Technologia ma spełnić trzy zadania.

• Ograniczyć ryzyko – brak krytycznych luk bezpieczeństwa, brak zależności od jednej osoby w zespole, brak „czarnej skrzynki”, którą trzeba będzie przepisać w panice.
• Potwierdzić potencjał wzrostu – architektura, którą da się skalować, proces developerski, który uniesie większy zespół, oraz infrastruktura, którą da się przewidywalnie kosztowo rozbudowywać.
• Zrozumieć historię decyzji technicznych – dlaczego powstał monolit, skąd się wzięły mikroserwisy, na jakim etapie pojawił się dług technologiczny i jak nim zarządzano.

Jeśli założyciele potrafią spójnie opowiedzieć historię decyzji technicznych i pokazać ją w dokumentacji technicznej dla inwestora (np. ADR-y, diagramy), audyt zaczyna się od zaufania, nie od podejrzliwości.

Miejsce due diligence w procesie inwestycyjnym

Zakres i głębokość audytu zależą od etapu rundy.

• Pre-seed – często tylko „light DD”: krótki przegląd repo, demo, rozmowa z CTO. Chodzi głównie o sprawdzenie, czy założyciele faktycznie umieją dowieźć produkt i czy widać elementarny porządek.
• Seed – inwestor oczekuje pierwszych procesów: prosty CI/CD, jakieś testy, podstawowa dokumentacja architektury. Dług technologiczny w startupie jest normalny, ale powinien być nazwany i kontrolowany.
• Seria A i dalej – pełny audyt technologiczny: bezpieczeństwo i compliance w SaaS, szczegółowa ocena architektury systemu, praktyk DevOps, monitoringu, backupów, procesu wydawania wersji, a nawet struktury zespołu technicznego.

Im wyższa runda, tym mniej inwestor toleruje „hackerskie” usprawiedliwienia w stylu „to tylko MVP”. Na pewnym poziomie takie deklaracje są traktowane jako sygnał ostrzegawczy, że firma nie przeszła na etap profesjonalizacji.

Zakres: kod, architektura, infrastruktura, bezpieczeństwo i ludzie

Typowe due diligence technologiczne obejmuje co najmniej:

• Kod źródłowy – struktura repozytoriów, jakość, testy, zależności, standardy.
• Architektura systemu – podział na moduły/usługi, komunikacja, baza danych, integracje.
• Infrastrukturę – chmura vs on-prem, konfiguracja, automatyzacja, monitoring, logowanie.
• Bezpieczeństwo i compliance – zarządzanie tajnymi kluczami, uprawnieniami, logami, zgodność z RODO/GDPR, branżowymi regulacjami.
• Procesy i zespół – sposób pracy, review, deployment, rotacja w zespole, bus factor.

Jeżeli któryś z tych obszarów jest kompletnie „białą plamą” (np. brak jakiejkolwiek kontroli dostępu do danych produkcyjnych), inwestor zwykle powiąże to z wyższym ryzykiem prawnym i operacyjnym, a tym samym niższą wyceną lub dodatkowymi warunkami inwestycji.

Light DD a pełny audyt zewnętrzny

Przy mniejszych rundach inwestorzy często stosują light due diligence technologiczne, prowadzone siłami własnego partnera technicznego lub zaprzyjaźnionego eksperta. To zwykle:

• kilka godzin przeglądu repozytorium (read-only),
• spotkanie z CTO / głównym developerem,
• prosty raport z listą ryzyk i rekomendacji.

Pełny audyt zewnętrzny pojawia się zwykle przy większych rundach lub przejęciach. Wtedy firma audytorska lub software house z doświadczeniem M&A dostaje:

• dostępy do repo, CI/CD, środowisk stagingowych,
• pakiet dokumentów technicznych,
• możliwość zadawania szczegółowych pytań całemu zespołowi technicznemu.

Jeśli założyciel traktuje każde DD jak formalność, często nie przygotowuje repozytorium, dokumentacji i zespołu. Efekt jest prosty: inwestor widzi chaos i niedojrzałość, nawet jeśli sam produkt na zewnątrz wygląda dobrze.

Jak wygląda przebieg due diligence technologicznego krok po kroku

Wstępne rozpoznanie: deck, demo i pierwsze repo

Pierwszy etap to zwykle desk research po stronie inwestora. Zanim pojawi się jakikolwiek dostęp do kodu, analizowane są:

• pitch deck i opis produktu (obietnica funkcjonalna i skala),
• demo produktu lub dostęp do środowiska testowego,
• architektura systemu na slajdzie, jeśli jest dostępna,
• CV/LinkedIn CTO oraz kluczowych osób technicznych.

Na tym etapie inwestor porównuje historię, którą słyszy w pitchu, z tym, co widzi w działającym produkcie. Jeśli deck mówi o „wysoce skalowalnym, event-driven systemie w chmurze”, a demo ledwo działa w jednej instancji, zapala się pierwsza lampka. Gdy pierwsze wrażenie jest spójne, inwestor przechodzi do głębszego audytu.

Ustalenie zakresu i dostępów

Przed wejściem w szczegóły powstaje zakres due diligence technologicznego. Po stronie startupu powinien pojawić się jeden właściciel procesu – zwykle CTO – który:

• koordynuje przekazywanie dostępów (read-only do repo, podgląd CI/CD, dostęp do stagingu),
• zbiera i wysyła dokumentację (diagramy, ADR-y, polityki bezpieczeństwa),
• organizuje spotkania z odpowiednimi członkami zespołu.

Typowe dostępy udzielane na czas audytu to:

• read-only do głównych repozytoriów kodu,
• read-only do narzędzi CI/CD (np. GitHub Actions, GitLab CI, CircleCI),
• dostęp do środowiska testowego lub staging,
• eksport logów z systemów monitoringu (np. uptime, błędy 5xx),
• dostęp tylko do odczytu do konfiguracji infrastruktury (np. Terraform, CloudFormation).

Jeśli startup na tym etapie nie potrafi sprawnie udzielić kontrolowanych dostępów (bo nie ma ról, uprawnień, wszystko jest na jednym koncie foundera), inwestor widzi punkt kontrolny: słabe zarządzanie bezpieczeństwem i brak dojrzałości operacyjnej.

Etapy audytu: dane, analiza, pytania, wnioski

Pełny proces due diligence technologicznego składa się zwykle z czterech etapów.

1. Zbieranie danych – eksport statystyk z repo (commity, contributorzy), przegląd struktury katalogów, konfiguracji buildów, backupów, polityk dostępu, przegląd logów błędów, zebranie dokumentacji technicznej.
2. Analiza – eksperci techniczni inwestora lub zewnętrzna firma audytowa oceniają kod, architekturę systemu, dług technologiczny, jakość procesu developerskiego i bezpieczeństwo.
3. Sesja pytań i odpowiedzi – doprecyzowanie niejasności, prośby o wyjaśnienie przestarzałych komponentów, brakujących testów, nietypowych decyzji architektonicznych.
4. Raport końcowy – lista ryzyk, klasyfikacja ich ważności (wysokie/średnie/niskie), szacowany koszt redukcji długu technologicznego, rekomendacje dla inwestora.

Dobrym sygnałem jest to, że CTO potrafi odpowiedzieć na trudne pytania bez uciekania w ogólniki. Jeśli na pytanie o backupy odpowiada „cloud provider to ogarnia”, a na temat testów „mamy kilka, ale nie wiem gdzie”, inwestor dopisuje kolejne punkty do listy ryzyk.

Format raportu i szacowanie kosztu długu technologicznego

Końcowy raport audytu najczęściej ma strukturę zorientowaną na decyzję inwestycyjną, a nie na szczegółowe wskazówki dla developerów. Pojawiają się elementy:

• Lista ryzyk technicznych – np. brak testów krytycznych modułów, przestarzałe biblioteki, single point of failure w architekturze.
• Priorytety – podział na ryzyka krytyczne (warunek inwestycji), ważne (do adresowania w ciągu X miesięcy) i mniej istotne.
• Szacunkowy koszt redukcji długu technologicznego – ile roboczogodzin, jakiego typu specjalistów, jaki wpływ na roadmapę produktu.
• Ogólna ocena dojrzałości technicznej – np. w skali opisowej od „chaotyczne MVP” do „profesjonalnie zarządzana platforma”.

Gdy raport pokazuje znaczny dług technologiczny, ale z jasną mapą spłaty, inwestor może zaakceptować sytuację, korygując wycenę lub dodając warunki (np. część środków znaczone na restrukturyzację architektury). Jeśli dług jest wysoki, a zespół nie ma świadomości jego zakresu – ryzyko jest zwykle nieakceptowalne.

Czas trwania due diligence technologicznego

Orientacyjnie:

• proste MVP, jeden repozytorium, kilku developerów – od 3 do 5 dni roboczych „light DD” przy dobrej współpracy,
• rozbudowany system SaaS z kilkunastoma repo, mikroserwisami, wieloma integracjami – od 2 do 4 tygodni pełnego audytu, w zależności od zakresu.

Jeżeli proces ciągnie się miesiącami, często nie dlatego, że inwestor tak długo analizuje, ale dlatego, że po stronie startupu brakuje jednego właściciela, dostępów, dokumentacji i szybkiej ścieżki odpowiedzi na pytania. Taki chaos organizacyjny jest dla inwestora równie istotny, jak same problemy w kodzie.

Jeśli due diligence technologiczne ma jasno wskazanego właściciela, przygotowane repozytoria i dokumentację, a zespół techniczny odpowiada spójnie na pytania – inwestor widzi zorganizowaną strukturę. Jeżeli każdy etap to improwizacja, opóźnienia i tłumaczenia „musimy sprawdzić, kto ma dostęp”, rośnie przekonanie, że tak samo chaotycznie wygląda codzienna praca nad produktem.

Co inwestor widzi w kodzie: kryteria jakości i sygnały ostrzegawcze

Struktura repozytoriów jako pierwszy punkt kontrolny

Struktura repozytoriów jest dla audytora tym, czym plan miasta jest dla urbanisty. Pierwsze spojrzenie mówi, czy ktoś w ogóle myślał o organizacji. Kluczowe elementy, na które patrzy inwestor:

• Liczba repozytoriów i ich rola – jedno ogromne, chaotyczne repo z backendem, frontendem, skryptami i infrastrukturą w jednym katalogu to klasyczny sygnał ostrzegawczy; dobrze wydzielone komponenty (np. infra-as-code osobno, frontend osobno, core backend osobno) świadczą o przemyślanym podejściu.
• Konsekwentna struktura katalogów – jasne rozdzielenie warstw (np. domain/application/infrastructure), brak „misc”, „tmp”, „new” pełnych krytycznego kodu.
• Standard nazewnictwa – spójne nazwy modułów, plików, testów, branchy; brak mieszanki polskiego, angielskiego i skrótów, które rozumie tylko autor.

Historia commitów i higiena pracy z Gitem

Po strukturze repo audytor przechodzi do historii zmian. Git pokazuje kulturę zespołu lepiej niż jakikolwiek slajd. Analizowane są m.in.:

• Wzorce commitów – czy są małe, opisowe, logicznie powiązane z zadaniami, czy raczej masowe „fix”, „changes”, „poprawki” bez sensownego opisu.
• Praca na branchach – czy istnieje spójna strategia (np. trunk-based, GitFlow), czy wszyscy pracują na master/main, wpychając bezpośrednio na produkcję.
• Code review – liczba merge commitów bez przeglądu, typowe komentarze w PR, obecność checklist jakościowych (testy, bezpieczeństwo, dokumentacja).
• Aktywność i rozkład pracy – czy kod utrzymuje jedna osoba („hero developer”), czy widać realny wkład kilku członków zespołu.

Historia commitów bywa pierwszym dowodem na to, że proces istnieje tylko w prezentacji. Jeśli 90% commitów to „quick fix” w piątek wieczorem, inwestor widzi chroniczne gaszenie pożarów. Gdy widać małe, opisowe commity, przeglądane przez innych, rośnie zaufanie do zespołu i dojrzałości procesu.

Styl kodu, czytelność i konsekwencja

Styl kodu nie jest kwestią gustu, lecz kosztu utrzymania. Audytor sprawdza przede wszystkim:

• Spójność stylu – jednolite konwencje formatowania, nazewnictwa, struktury plików; obecność lintersów, formatterów i reguł CI blokujących niespójny kod.
• Czytelność funkcji i klas – długość metod, liczba parametrów, obecność martwego kodu, komentarze wyjaśniające „dlaczego”, a nie „co” robi fragment.
• Granice odpowiedzialności – brak „god classes” i modułów robiących wszystko; sensowne podziały na warstwy i moduły domenowe.

Kod może być napisany w dowolnym frameworku, ale jeśli wymaga godzin, by zrozumieć jedną ścieżkę biznesową, inwestor zakłada wysokie koszty onboardingu i modyfikacji. Gdy przepływy są krótkie, klarowne i dobrze nazwane, nawet przy ograniczonej testowalności, ogólny odbiór jest pozytywny.

Testy automatyczne i pokrycie krytycznych ścieżek

Testy są dla inwestora jednym z kluczowych wskaźników kontrolowalności ryzyka. Analiza obejmuje:

• Poziom testów – ile jest testów jednostkowych, integracyjnych i end-to-end; czy pokrywają główne scenariusze biznesowe.
• Jakość, nie tylko ilość – czy testy są deterministyczne, szybkie, opisowe; czy testują sensowne przypadki, czy jedynie „szczęśliwe ścieżki”.
• Integracja z CI – czy testy odpalają się przy każdym PR i blokują merge w razie błędów.

Nieważne, że raport pokrycia pokazuje wysokie procenty, jeśli testy omijają krytyczne moduły: płatności, provisioning użytkowników, integracje z partnerami. Gdy krytyczne ścieżki mają solidne testy, inwestor jest spokojniejszy o stabilność wzrostu i tempo wprowadzania zmian.

Zależności zewnętrzne i zarządzanie bibliotekami

Inwestor patrzy także na ekosystem zależności, nie tylko na własny kod. Kluczowe punkty kontrolne:

• Aktualność bibliotek – obecność przestarzałych, niewspieranych zależności, szczególnie w obszarach bezpieczeństwa, płatności, autentykacji.
• Zarządzanie wersjami – czy istnieje polityka aktualizacji (np. kwartalne przeglądy), lockfile w repo, automatyczne alerty (Dependabot, Renovate).
• Zależności „vendor lock-in” – mocne przywiązanie do jednego dostawcy chmury, specyficznych usług PaaS bez planu ewentualnej migracji.

Stosowanie popularnych bibliotek jest normalne, dopóki zespół ma świadomość ich cyklu życia. Gdy audyt wykrywa krytyczne komponenty oparte na porzuconych projektach open source, inwestor dopisuje wysoki koszt potencjalnej migracji.

Bezpieczeństwo w kodzie aplikacyjnym

Aspekty bezpieczeństwa nie kończą się na konfiguracji firewalla. W samym kodzie audytor szuka m.in.:

• Walidacji danych wejściowych – obecności sanitizacji danych, ochrony przed SQL/NoSQL injection, XSS, CSRF.
• Przechowywania sekretów – czy klucze API, hasła, tokeny nie leżą w repo lub w konfiguracji bez szyfrowania.
• Obsługi błędów – czy komunikaty błędów nie ujawniają zbyt wielu szczegółów (stack trace na produkcji, informacje o strukturze bazy).

Jeśli w repo znajdują się klucze produkcyjne lub dane klientów w plikach testowych, jest to natychmiastowy sygnał ostrzegawczy. Gdy widać systematyczne stosowanie wzorców bezpieczeństwa i rozdzielenie konfiguracji, ryzyko operacyjne istotnie spada.

Architektura systemu pod lupą: skalowalność, elastyczność, odporność

Model architektoniczny a etap rozwoju firmy

Inwestor nie oczekuje mikroserwisów przy 200 użytkownikach, ale oczekuje zgodności architektury z etapem wzrostu. Analizowane są:

• Proporcja prostoty do złożoności – czy architektura nie jest nadmiernie skomplikowana (np. kilkadziesiąt serwisów przy małym produkcie), co zwiększa koszt utrzymania.
• Możliwość ewolucji – czy obecny monolit można z czasem sensownie dzielić, czy już dziś wszystko jest silnie posklejane.
• Spójność z roadmapą – czy architektura utrzyma planowany wzrost funkcjonalny i geograficzny bez przepisywania wszystkiego od zera.

Jednolity, modularny monolit bywa dużo lepszym sygnałem niż chaotyczne pseudo-mikroserwisy. Jeśli plan ekspansji wymaga wielu integracji, a architektura jest hermetycznym monolitem bez interfejsów, inwestor widzi przyszłe blokady.

Skalowalność: pozioma, pionowa i organizacyjna

Skalowalność to nie tylko liczba instancji serwera. Audyt obejmuje trzy płaszczyzny:

• Skalowanie techniczne – możliwość dodawania instancji bez przeróbek kodu, brak ciasnych zależności stanowych, wykorzystanie load balancerów, cache, kolejek.
• Skalowanie danych – strategie partycjonowania, archiwizacji, mechanizmy radzenia sobie z rosnącym wolumenem danych (logi, eventy, pliki).
• Skalowanie zespołu – jasne granice modułów, które pozwalają kilku zespołom pracować równolegle bez nieustannych konfliktów.

Jeśli cały system działa na jednej maszynie z jedną bazą i lokalnym stanem sesji, a pitch mówi o globalnej ekspansji, powstaje luka między narracją a rzeczywistością. Gdy widać choćby podstawowe mechanizmy poziomego skalowania, a zespół rozumie swoje ograniczenia, inwestor zwykle akceptuje etap przejściowy.

Elastyczność: integracje, API i separacja domen

Elastyczność architektury mierzona jest tym, jak łatwo system łączy się z innymi. Sprawdzane są:

• Projekt API – spójność kontraktów, wersjonowanie, dokumentacja (OpenAPI/Swagger), strategie zmian wstecznie kompatybilnych.
• Warstwa integracyjna – czy integracje z zewnętrznymi usługami są izolowane (adaptery, antykorupcyjne warstwy), czy logika biznesowa miesza się bezpośrednio z kodem SDK dostawcy.
• Moduły domenowe – oddzielenie kluczowych domen (płatności, subskrypcje, użytkownicy) od warstwy prezentacji i narzędzi.

System mocno wklejony w jednego dostawcę płatności bez jasnej warstwy abstrakcji to ryzyko negocjacyjne i regulacyjne. Gdy integracje są zamknięte w dedykowanych modułach, migracja czy dodanie nowych partnerów jest wykonalne bez paraliżowania całego produktu.

Odporność: awarie, retry i degradacja funkcjonalna

Odporność systemu wychodzi na jaw dopiero w stresie. Inwestor szuka śladów przygotowania na awarie:

• Mechanizmy retry i timeout – czy połączenia zewnętrzne mają ograniczone timeouty, kontrolowane ponawianie prób, backoff; czy brak odpowiedzi partnera nie blokuje całego systemu.
• Degradacja funkcjonalna – które funkcje mogą być wyłączone przy problemach (feature flags, tryb read-only) bez zatrzymania kluczowych procesów.
• Monitoring i alerting – metryki techniczne (CPU, RAM, latencja) oraz biznesowe (liczba płatności na minutę, odrzucone logowania) powiązane z alertami.

Jeśli każda awaria małego komponentu powoduje globalny downtime, a logi są jedynym mechanizmem „monitoringu”, inwestor wycenia wyżej ryzyko SLA. Gdy widać choćby podstawową obsługę błędów i świadome decyzje o tym, co może się „elegancko zepsuć”, ocena jest znacznie lepsza.

Architektura danych i zgodność regulacyjna

Struktura przechowywania danych jest podwójnym punktem kontrolnym: technicznym i prawnym. Audytor patrzy na:

• Podział danych – separacja danych klientów, izolacja danych wrażliwych, strategie multi-tenant (osobne schematy, bazy, klucze partycjonujące).
• Retencję – polityki przechowywania, anonimizacji i usuwania; zgodność z wymaganiami prawnymi (np. konieczność „right to be forgotten”).
• Szyfrowanie – dane w spoczynku i w tranzycie, zarządzanie kluczami, dostęp administracyjny do danych produkcyjnych.

System, który przechowuje wszystkie dane użytkowników w jednym niezaszyfrowanym zbiorze, jest poważnym ryzykiem reputacyjnym i prawnym. Gdy mechanizmy separacji i retencji są dopracowane, a ich działanie udokumentowane, inwestor widzi mniejsze ryzyko kar i incydentów.

Dług technologiczny – kiedy jest akceptowalny, a kiedy dyskwalifikuje

Rodzaje długu technologicznego z perspektywy inwestora

Dług technologiczny nie jest jednorodny. Z punktu widzenia inwestora można wyróżnić kilka jego kategorii:

• Dług świadomy – celowe uproszczenia (np. brak pełnej automatyzacji, ręczne procesy) z jasno opisanym planem spłaty.
• Dług nieświadomy – przestarzałe decyzje, brak testów, chaotyczna architektura, o których zespół nie potrafi jasno opowiedzieć.
• Dług strukturalny – wybory architektoniczne, które blokują kluczowe kierunki rozwoju (np. multi-region, B2B2C, white-label).
• Dług operacyjny – brak monitoringu, backupów, automatyzacji deploymentu, powodujący wysokie ryzyko awarii i „ręcznego” zarządzania.

Świadomy dług z planem spłaty jest akceptowalny i często naturalny na wczesnym etapie. Nieświadomy, zwłaszcza w obszarach bezpieczeństwa czy danych, bywa sygnałem dyskwalifikującym, bo pokazuje brak kontroli nad fundamentami.

Kiedy dług jest rozsądnym kompromisem

Dług technologiczny jest obroniony, gdy spełnia kilka minimalnych warunków:

• Jest policzony – CTO potrafi oszacować, ile czasu i jakich kompetencji wymaga redukcja długu w kluczowych obszarach.
• Ma priorytety – istnieje lista „top 5” długów z przypisanymi terminami, a nie ogólne „wiemy, że trzeba posprzątać”.
• Nie blokuje core KPI – mimo długu, zespół jest w stanie dowozić funkcje wspierające wzrost MRR, retencję, ekspansję.

Jeśli CTO mówi wprost: „ten moduł napisaliśmy szybko, bo ważniejszy był market-fit, ale mamy plan wydzielenia go w ciągu X miesięcy”, inwestor ocenia sytuację jako kontrolowaną. Gdy słyszy, że „tak wyszło, jakoś to będzie”, uznaje, że brak jest zarządzania ryzykiem technologicznym.

Strefy czerwone: dług, który podcina wartość inwestycji

Są obszary długu, które często prowadzą do negatywnej decyzji inwestycyjnej, niezależnie od potencjału biznesowego. Typowe czerwone flagi:

• Brak minimalnych zabezpieczeń – brak backupów, brak jakichkolwiek testów krytycznych modułów, twardo zakodowane dane dostępowe.
• Nierozdzielny monolit – architektura, której nie da się skalować ani modyfikować bez globalnego refaktoringu, przy jednoczesnych planach szybkiej ekspansji.
• Kluczowa wiedza w głowie jednej osoby – brak dokumentacji, brak code review, brak rotacji zadań.
• Licencje i prawa do kodu – fragmenty kodu bez jasnego prawa własności (freelancerzy bez umów przenoszących prawa, kopiowanie rozwiązań z projektów klientów).

Jak pokazać dług technologiczny inwestorowi bez strzelania sobie w stopę

Podczas due diligence nie chodzi o ukrywanie problemów, tylko o pokazanie, że są one pod kontrolą. Techniczny lider, który potrafi przejść po swoich słabościach w sposób uporządkowany, często budzi większe zaufanie niż ten, który utrzymuje, że „u nas wszystko jest w porządku”. Kluczowe są trzy elementy prezentacji długu:

• Mapa długu – uporządkowana lista obszarów z krótkim opisem ryzyka (np. „brak testów integracyjnych w module faktur – ryzyko regresji przy zmianach stawek VAT”).
• Szacunek kosztu – realistyczna estymacja czasowo-zasobowa (np. „wydzielenie modułu płatności: 2 osoby przez 6–8 tygodni, wymagane doświadczenie w X/Y”).
• Plan redukcji – konkretny plan: co będzie zrobione przed rundą, co po rundzie, a co dopiero przy określonej skali (np. po wejściu na rynek kolejnego kraju).

Jeśli zespół pokazuje dług w formie uporządkowanego backlogu z priorytetami i akceptowanym ryzykiem, inwestor widzi zarządzanie, a nie chaos. Gdy zamiast tego pojawia się ogólna narracja „najpierw rośniemy, potem posprzątamy” bez konkretów – to wyraźny sygnał ostrzegawczy.

Obszary, w których dług jest względnie bezpieczny

Są fragmenty stosu technologicznego, w których dług zwykle nie jest krytyczny, o ile nie rozlewa się na obszary core biznesu. Typowe „bezpieczne” miejsca to:

• Panel administracyjny – narzędzia wewnętrzne, nawet częściowo ręczne czy brzydkie UI, pod warunkiem, że nie blokują skalowania operacji w średnim horyzoncie.
• Automatyzacja procesów – brak w pełni zautomatyzowanych pipeline’ów, jeśli deployment jest powtarzalny, udokumentowany i bezpieczny.
• Raportowanie pomocnicze – niestabilne raporty „nice-to-have”, jeśli dane krytyczne (np. rozliczenia z klientami) są liczone i weryfikowane solidnie.

Jeśli dług dotyczy rzeczy, które „męczą” zespół, ale nie ryzykują utraty danych, złamania prawa ani blokady skalowania, inwestor często przyjmuje je jako naturalny koszt wczesnego etapu. Kiedy jednak problemy z narzędziami wewnętrznymi uniemożliwiają obsługę większej liczby klientów bez wielokrotnego zwiększania liczby ludzi, staje się to już punktem kontrolnym dla całego modelu biznesowego.

Dług technologiczny a wycena – mechanika wpływu

Podczas negocjacji inwestor przekształca obserwowany dług w koszt przyszłych prac i ryzyka, które musi „wkalkulować” w wycenę. Najczęściej odbywa się to w trzech wymiarach:

• Oczekiwane CAPEX technologiczny – ile środków z rundy musi realnie pójść na naprawę fundamentów, zanim pieniądze zaczną napędzać wzrost.
• Dyskonto za ryzyko – niższa wycena, jeśli prawdopodobieństwo poważnego incydentu (awaria, data breach, utrata kluczowego programisty) jest wyraźnie podwyższone.
• Warunki inwestycji – dodatkowe kowenanty techniczne (np. „wdrożenie testów regresyjnych do X daty”) albo transze zależne od wykonania określonych prac naprawczych.

Jeśli zespół ma policzony dług i pokaże racjonalny plan jego redukcji, wpływ na wycenę zwykle ogranicza się do lekkiego dyskonta. Jeżeli natomiast audyt ujawnia „bombę z opóźnionym zapłonem” (np. poważne luki w bezpieczeństwie, brak praw do kodu), inwestor może mocno obniżyć ofertę lub w ogóle się wycofać.

Strategie redukcji długu po inwestycji

Po zamknięciu rundy pojawia się pokusa, by wszystkie problemy „naprawić od razu”. Z perspektywy inwestora sensowna jest kontrolowana kolejność. Typowa sekwencja prac naprawczych, którą audytorzy uznają za zdrową:

• Najpierw bezpieczeństwo i dane – uszczelnienie dostępu, szyfrowanie, procesy backupu i odtwarzania, procedury incydentowe.
• Później stabilność i operacje – monitoring, alerting, podstawowe testy automatyczne, sane deployment (CI/CD w minimalnym zakresie).
• Na końcu optymalizacja architektury – refaktory monolitu, rozdzielanie modułów, nowe technologie bazodanowe, migracje do mikroserwisów.

Jeśli roadmapa po rundzie zaczyna się od ambitnych re-architektur i przepisywania całego systemu, a pomija zabezpieczenia i procesy operacyjne, inwestor widzi ryzyko „przepalania” kapitału. Gdy priorytety odpowiadają hierarchii ryzyka (najpierw to, co może zatrzymać biznes lub narazić na kary), perspektywa dalszego finansowania staje się dużo bardziej realna.

Jak przygotować się do due diligence technologicznego przed rozmową z inwestorem

Minimum dokumentacji, które powinno istnieć

Inwestor nie oczekuje rozbudowanej dokumentacji korporacyjnej przy wczesnym produkcie, ale pewne minimum dokumentacyjne jest punktem kontrolnym dojrzałości zespołu. Zestaw bazowy to:

• Opis architektury wysokiego poziomu – prosty diagram komponentów (aplikacje, bazy, usługi zewnętrzne) z krótkimi opisami odpowiedzialności.
• Mapa domen biznesowych – podział na obszary (np. billing, onboarding, komunikacja) i wskazanie, w których komponentach żyje która domena.
• Proces wytwórczy – krótki opis: jak powstają zmiany, jak są testowane, kto zatwierdza releasy, jak działają roll-backi.
• Procedury krytyczne – backup i odtwarzanie, reagowanie na incydenty bezpieczeństwa, zarządzanie dostępami.

Jeśli zespół potrafi w ciągu kilkunastu minut przeprowadzić inwestora przez aktualny obraz systemu na bazie tych materiałów, audyt techniczny przyspiesza, a rozmowa schodzi na konkretne ryzyka i plany. Brak jakiejkolwiek dokumentacji, nawet w formie szkicu w repozytorium, jest sygnałem, że cała wiedza tkwi w głowach kilku osób.

Przegląd kodu „wewnętrzny” przed audytem

Zanim kod trafi na biurko audytora, rozsądny zespół przeprowadza wewnętrzny przegląd krytycznych obszarów. Nie chodzi o przepisywanie wszystkiego, lecz o kilka szybkich działań higienicznych:

• Usunięcie oczywistych antywzorców – zakomentowane wielkie bloki kodu, twardo zakodowane dane dostępowe, martwe moduły dawno nieużywane w produkcji.
• Dodanie minimalnych testów dymnych – kilka testów, które przechodzą przez główne ścieżki biznesowe (np. rejestracja, płatność, generowanie faktury).
• Przegląd zależności – aktualizacja krytycznych bibliotek bezpieczeństwa, usunięcie zupełnie nieużywanych pakietów.

Jeśli audytor widzi w repozytorium świeże commity porządkujące oczywiste problemy, traktuje to jako sygnał, że zespół potrafi szybko reagować na uwagi. Jeżeli już na wejściu natyka się na hasła w kodzie i przypadkowe pliki dumpów bazy, zaufanie gwałtownie spada.

Przygotowanie środowiska demonstracyjnego

Dobry audyt wymaga dostępu do reprezentatywnego środowiska. Z punktu widzenia inwestora najlepiej, gdy jest to odseparowane środowisko z realistycznymi danymi testowymi. Przygotowanie obejmuje:

• Maskowanie danych – zastąpienie realnych danych klientów danymi syntetycznymi lub zanonimizowanymi, przy zachowaniu typowych objętości i przypadków brzegowych.
• Replikę konfiguracji produkcyjnej – tak zbliżoną, jak to możliwe: te same typy baz, podobne plany usług w chmurze, podobne limity.
• Dostępy i ścieżki audytu – konta z odpowiednimi rolami, logowanie operacji audytora, jasne instrukcje: jak się zalogować, jak wykonać typowe operacje.

Jeśli przygotowanie środowiska testowego wymaga tygodni i ręcznych, niepowtarzalnych działań, inwestor od razu widzi problem z procesami DevOps. Gdy uruchomienie kompletnego środowiska to odpalanie kilku skryptów lub pipeline’u, ocena dojrzałości technicznej rośnie.

Spójna narracja między pitch deckiem a stanem technicznym

Częsty problem to rozjazd historii sprzedażowej z realną architekturą. Pitch mówi o „zaawansowanej AI” i „architekturze mikroserwisowej gotowej na miliony użytkowników”, podczas gdy w kodzie widać pojedynczy skrypt Pythona i monolit PHP na jednym serwerze. Inwestor nie wymaga perfekcji, natomiast wymaga uczciwości:

• Unikanie przerysowań – jeśli „AI” oznacza kilka heurystyk i prosty model, lepiej tak to nazwać, a nie budować narrację o własnej platformie ML.
• Jasne oznaczanie planów – wyraźne oddzielenie tego, co istnieje dziś, od tego, co jest w roadmapie (najlepiej z przewidywanym zakresem czasowym).
• Spójność diagramów – architektura w decku powinna odzwierciedlać stan rzeczywisty, ewentualnie z zaznaczeniem planowanych komponentów jako „future state”.

Jeżeli audytor rozpoznaje, że slajdy są uczciwym obrazem aktualnego stanu + jasno oznaczonej przyszłości, traktuje zarząd jako partnerów do rozmowy. Gdy odkrywa rozdźwięk między narracją marketingową a faktami, nawet solidny kod nie zrekompensuje utraty zaufania.

Rola CTO i zespołu inżynierskiego w procesie due diligence

CTO jako tłumacz między biznesem a technologią

Podczas due diligence techniczne decyzje muszą zostać osadzone w kontekście biznesowym. Inwestor potrzebuje kogoś, kto potrafi opowiedzieć, dlaczego dany kompromis ma sens przy danej strategii wzrostu. Oczekiwane postawy CTO:

• Transparentność – jasne przyznanie: „tutaj jest dług, wzięliśmy go świadomie z powodu X, planujemy spłatę w Y kwartale”.
• Decyzyjność – umiejętność bronienia decyzji technicznych nie argumentem „tak się przyjęło”, lecz konkretem: koszt alternatywy, czas, ryzyko.
• Umiejętność priorytetyzacji – pokazanie, które obszary są krytyczne z punktu widzenia KPI, a które można poprawiać iteracyjnie.

Jeśli CTO potrafi samodzielnie, klarownie wyjaśnić architekturę i ryzyka bez zasłaniania się zespołem, inwestor widzi lidera zdolnego dowieźć roadmapę po rundzie. Jeśli każda bardziej szczegółowa odpowiedź wymaga przekierowania do poszczególnych programistów, rodzi się pytanie o realny poziom sterowania techniką.

Zaangażowanie seniorów technicznych w rozmowę

Sama obecność CTO nie zawsze wystarcza. Przy bardziej złożonych produktach sensowne jest włączenie senior inżynierów odpowiedzialnych za kluczowe obszary (np. bezpieczeństwo, dane, integracje). Ich rola to:

• Pokazanie głębi – odpowiedzi na pytania szczegółowe (np. jak rozwiązano obsługę konfliktów w modelu multi-tenant, jak działają migracje schematu bazy).
• Zaprezentowanie kultury inżynieryjnej – sposób, w jaki zespół rozmawia o problemach, przyjmuje krytykę, reaguje na trudne pytania.
• Uwiarygodnienie planów – weryfikacja, czy deklarowane przez zarząd plany technologiczne są realne z punktu widzenia wykonawców.

Jeśli seniorzy potrafią w spójny sposób uzupełniać narrację CTO, inwestor widzi, że kultura techniczna jest zharmonizowana. Jeżeli wypowiedzi są sprzeczne albo zespół techniczny dowiaduje się o planach z prezentacji sprzedażowej, to silny sygnał ostrzegawczy.

Postawa wobec uwag audytora

Due diligence to nie egzamin z jedną oceną, ale również symulacja przyszłej współpracy. Inwestor obserwuje, jak zespół reaguje na feedback techniczny. Typowe punkty kontrolne:

• Obrona vs. otwartość – czy na każdą uwagę pojawia się automatyczna obrona („u nas to nie problem”), czy raczej pytanie: „co widzi pan/pani w innych spółkach i jak to zwykle rozwiązać?”.
• Gotowość na szybkie poprawki – chęć wprowadzenia prostych usprawnień jeszcze w trakcie procesu (np. poprawa konfiguracji backupu, dodanie logowania dostępu adminów).
• Rejestrowanie wniosków – spisywanie rekomendacji audytora i włączanie ich do backlogu, zamiast pozostawiania ich w sferze „fajnie, że pan/pani o tym wspomniał(a)”.

Jeżeli już na etapie audytu zespół pokazuje, że potrafi szybko wdrażać sensowne rekomendacje, inwestor zakłada podobną reakcję na przyszłe wyzwania skalowe. Gdy cały feedback jest zbywany, a każdy problem minimalizowany, rośnie obawa, że nawet oczywiste zagrożenia będą ignorowane.

Najczęściej zadawane pytania (FAQ)

Na czym polega due diligence technologiczne w startupie?

Due diligence technologiczne to uporządkowany audyt tego, co faktycznie stoi za produktem: kodu, architektury, infrastruktury, bezpieczeństwa i pracy zespołu. Inwestor chce odpowiedzi, czy da się bezpiecznie dowieźć skalę obiecaną w pitch decku oraz jaki jest realny poziom ryzyka technicznego.

Sprawdzane są m.in.: struktura repozytoriów, jakość kodu i testów, podział na moduły/usługi, konfiguracja chmury, proces wydawania wersji, zarządzanie danymi i uprawnieniami oraz bus factor w zespole. Jeśli w kilku kluczowych obszarach pojawia się chaos lub „białe plamy”, to dla inwestora mocny sygnał ostrzegawczy i powód do korekty wyceny.

Czym różni się due diligence technologiczne od zwykłego code review?

Code review dotyczy pojedynczych fragmentów kodu: czy są czytelne, zgodne ze standardami, bez oczywistych błędów. Due diligence technologiczne patrzy szerzej: obejmuje cały system, procesy developerskie, bezpieczeństwo, infrastrukturę oraz sposób pracy zespołu.

Audyt technologiczny nie zatrzymuje się na jednym „brzydkim” pliku. Szuka wzorców: powtarzającego się braku testów, chaotycznych zależności między modułami, braku standardów commitów czy niestabilnego procesu deploymentu. Jeśli problemy pojawiają się w wielu miejscach jednocześnie, to punkt kontrolny, że system może nie unieść wzrostu użytkowników ani zespołu.

Czego dokładnie szuka inwestor w due diligence kodu i architektury?

Inwestor patrzy przede wszystkim na trzy rzeczy: ograniczenie ryzyka, możliwość wzrostu i spójność historii decyzji technicznych. Interesuje go, czy nie ma krytycznych braków w bezpieczeństwie, czy system nie zależy od jednej osoby oraz czy architektura (monolit, mikroserwisy, event-driven) ma sens na deklarowaną skalę.

Typowe kryteria to m.in.: obecność testów (szczególnie dla kluczowych funkcji biznesowych), jasny podział odpowiedzialności między modułami, sensowne wykorzystanie usług chmurowych, monitoring i backupy oraz udokumentowane decyzje architektoniczne (np. ADR-y, diagramy). Jeśli założyciele potrafią logicznie wyjaśnić, skąd wziął się dług technologiczny i jak jest zarządzany, buduje to zaufanie zamiast podejrzliwości.

Na jakim etapie rundy inwestor robi pełne due diligence technologiczne?

Skala audytu rośnie wraz z rundą. Na pre-seed zwykle wystarczy „light DD”: szybki przegląd repozytorium, demo i rozmowa z CTO, żeby sprawdzić, czy zespół realnie potrafi dowozić. W rundzie seed inwestor oczekuje już podstawowych procesów: prostego CI/CD, pierwszych testów, szkicu dokumentacji architektury.

Pełne due diligence technologiczne pojawia się najczęściej od serii A i przy przejęciach. Obejmuje wtedy szczegółową analizę bezpieczeństwa i compliance (np. RODO/GDPR w SaaS), architektury systemu, konfiguracji infrastruktury, monitoringu, procesu releasów i struktury zespołu technicznego. Jeżeli na tym etapie startup nadal tłumaczy się „to tylko MVP”, to zwykle sygnał ostrzegawczy, że profesjonalizacja technologii została odłożona zbyt długo.

Jakie elementy są minimum przygotowania startupu do audytu technologicznego?

Minimum to kilka uporządkowanych obszarów. Po pierwsze: repozytoria z sensowną strukturą, historią commitów i choć podstawowymi testami automatycznymi. Po drugie: choćby prosta dokumentacja architektury – diagramy głównych komponentów, opis integracji i kluczowych decyzji technicznych.

Po trzecie: kontrolowane dostępy do infrastruktury i danych (rozdzielone role, brak jednego „root konta foundera” do wszystkiego). Po czwarte: podstawowy pipeline CI/CD i przewidywalny proces release’ów. Jeśli te minimum są spełnione, audyt zwykle koncentruje się na priorytetach rozwojowych; jeśli nie – większość raportu zajmą krytyczne braki, które obniżą zaufanie i wycenę.

Jak wygląda w praktyce „light DD” vs pełny audyt zewnętrzny?

Light DD trwa zwykle kilka godzin do jednego dnia. Inwestor lub jego ekspert dostaje dostęp tylko do odczytu do głównych repozytoriów, ogląda podstawową konfigurację CI/CD albo pyta o nią na spotkaniu, a następnie rozmawia z CTO lub głównym developerem. Efektem jest krótki raport: lista największych ryzyk i rekomendowanych usprawnień.

Pełny audyt zewnętrzny to osobny mini–projekt. Zewnętrzny zespół audytowy dostaje dostępy do repo, pipeline’ów CI/CD, środowisk stagingowych oraz pakiet dokumentów (diagramy, polityki bezpieczeństwa, ADR-y). Przeprowadza serię pogłębionych rozmów z zespołem technicznym i przygotowuje szczegółowy raport z oceną każdego obszaru. Jeżeli startup wchodzi w taki proces bez przygotowania (brak dokumentacji, brak ról, brak monitoringu), raport będzie katalogiem sygnałów ostrzegawczych zamiast dowodem dojrzałości.

Jak dług technologiczny wpływa na due diligence i wycenę startupu?

Dług technologiczny sam w sobie nie jest problemem – problemem jest dług, którego nikt nie zna, nie mierzy i nie planuje spłacać. W due diligence inwestor analizuje, czy dług jest świadomy i kontrolowany, czy raczej wynika z chaosu i braku procesów. Różnica między „świadomie odroczone refaktoryzacje” a „gliniane nogi systemu” jest kluczowa.

Jeśli zespół ma listę znanych długów, potrafi pokazać, które są krytyczne i jak zamierza je redukować, inwestor zwykle akceptuje je jako koszt tempa. Jeżeli dług wychodzi na jaw dopiero w audycie, w formie braku testów, braku bezpieczeństwa i „czarnej skrzynki” zależnej od jednej osoby, staje się to powodem do obniżenia wyceny lub wprowadzenia ostrych warunków inwestycji (np. obowiązkowego planu naprawczego przed kolejną transzą).

Opracowano na podstawie

• Software Engineering Body of Knowledge (SWEBOK) V3.0. IEEE Computer Society (2014) – Standardowe praktyki inżynierii oprogramowania, jakość kodu, testy, architektura.
• ISO/IEC 25010: Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE). International Organization for Standardization (2011) – Model jakości oprogramowania: niezawodność, bezpieczeństwo, łatwość utrzymania.
• Due Diligence for Venture Capital Investments. Harvard Business School Publishing – Opis procesu due diligence w VC, w tym rola analizy technologicznej.
• Technology Due Diligence: Best Practices for Evaluating Software and Systems. O’Reilly Media – Praktyczny przewodnik po audycie technologii, kodu i architektury w transakcjach.