Techniczna Lista Kontrolna Due Diligence dla Startupów Pre-Seed, Seed i Serii A (2026-2027)

Podpisanie dokumentu term sheet w rundzie Seed lub Serii A nie oznacza jeszcze przelewu na konto spółki — otwiera ono dwu- do czterotygodniowe okno weryfikacyjne, podczas którego niezależny ekspert CTO bada historię commitów na GitHubie, rachunki chmurowe, umowy z podwykonawcami oraz architekturę bezpieczeństwa. Występując po obu stronach technicznego due diligence startupów — zarówno jako audytorzy dla funduszy VC, jak i przygotowując założycieli w ramach praktyki Fractional CTO — wiemy doskonale, że inwestycje rzadko upadają przez formatowanie kodu. Transakcje wykolejają się na nieprzeniesionych prawach autorskich IP, wyciekach danych między klientami oraz ukrytej konieczności przepisania systemu od zera.

W latach 2026 i 2027 badanie techniczne stało się znacznie bardziej rygorystyczne. Ponieważ asystenci kodowania AI pozwalają wygenerować 50,000 linii efektownie wyglądającego interfejsu w miesiąc, sama liczba ekranów nie robi już na nikim wrażenia. Audytorzy weryfikują, czy zespół rozumie własny model danych, wymusza izolację uprawnień bezpośrednio w bazie SQL i utrzymuje zdrową marżę brutto.

Wykorzystaj poniższą siedmiofilarową techniczną listę kontrolną due diligence, aby samodzielnie ocenić spółkę na trzydzieści dni przed otwarciem pokoju danych (data room) — niezależnie od tego, czy budowałeś produkt wewnętrznie, ze specjalistami od oprogramowania dedykowanego, czy przejąłeś wczesny kod po agencji.

Filar 1: Czysty łańcuch praw majątkowych IP (Chain of Title). Prawnicy i audytorzy techniczni zestawiają wynik komendy git shortlog -sne bezpośrednio z podpisanymi umowami. Każda osoba, która kiedykolwiek wysłała choćby jeden commit — byli współzałożyciele, weekendowi freelancerzy, praktykanci czy zewnętrzne zespoły realizujące MVP outsourcing — musi posiadać podpisaną umowę z klauzulą bezwarunkowego przeniesienia autorskich praw majątkowych (wraz z polami eksploatacji i prawami zależnymi) na Twoją spółkę kapitałową (sp. z o.o., S.A. lub Delaware C-Corp). Uważaj na dwie klasyczne pułapki: kod pisany przed rejestracją spółki podczas pracy na etacie w innej firmie bez wyłączenia praw pracodawcy oraz umowy z software house'ami zatrzymującymi prawa do tzw. „bazowego frameworku”. Równie ważne: organizacja GitHub, domeny DNS, główne konta AWS/GCP/Vercel oraz Stripe muszą należeć bezpośrednio do spółki.

Filar 2: Skażenie wirusowymi licencjami open source. Audytorzy uruchamiają automatyczne skanery SBOM (syft, trivy lub license-checker) na plikach package-lock.json, requirements.txt oraz obrazach Docker. Licencje permisywne (MIT, Apache-2.0, BSD-3) przechodzą bez uwag. Wpięcie wirusowych bibliotek copyleft (AGPLv3, GPLv3 lub SSPL) bezpośrednio do własnościowego backendu SaaS może prawnie wymusić ujawnienie Twojego kodu źródłowego, wstrzymując podpisanie umowy inwestycyjnej do czasu wymiany paczki.

Fundusz finansuje rundę z założeniem pięcio- lub dziesięciokrotnego wzrostu liczby klientów w ciągu kolejnych osiemnastu miesięcy. Filar 3 sprawdza, czy podłączenie 200 nowych firm B2B odbędzie się płynnie, czy wymusi półroczne zamrożenie rozwoju funkcji.

W pierwszej kolejności audytorzy przeglądają migracje bazodanowe, indeksy i zapytania ORM. Czy schemat wymusza twarde granice między organizacjami poprzez złożone indeksy tenant_id oraz mechanizm PostgreSQL Row-Level Security (RLS), zgodnie ze wzorcami opisanymi w naszym przewodniku po architekturze multi-tenant SaaS? Czy może pojedyncze pominięte WHERE w nowym endpoincie API pozwala Klientowi A podejrzeć faktury Klienta B? Sprawdzane jest również to, czy wszystkie zmiany schematu przechodzą przez wersjonowane migracje (Prisma, Drizzle, Alembic) zamiast ręcznych komend SQL na produkcji.

Następnie badane są wąskie gardła synchroniczne i pętle zapytań N+1: ciężkie przetwarzanie PDF, ponowienia webhooków oraz masowe eksporty CSV muszą działać w trwałych kolejkach asynchronicznych. Porównaj swój backend z naszym przewodnikiem bezpieczeństwa i skalowalności MVP, aby wcześnie wyłapać ograniczenia.

Ostatnie dziewięćdziesiąt dni pull requestów na GitHubie bezbłędnie pokazuje prawdziwą kulturę inżynierską firmy. Zdrowe zespoły Seed wdrażają codziennie małe, sprawdzone pull requesty przez automatyczne potoki CI/CD; zespoły pogrążone w chaosie łączą raz w miesiącu gigantyczną gałąź liczącą 8,000 linii kodu i spędzają kolejny tydzień na gaszeniu awarii.

Na etapie Seed nikt nie oczekuje 90% sztucznego pokrycia testami jednostkowymi na szybko zmieniającym się interfejsie. Audytorzy szukają testów integracyjnych o wysokiej dźwigni obejmujących logowanie, granice uprawnień między klientami, webhooki rozliczeniowe Stripe oraz kluczowe zapisy danych. Dodaj do tego strukturalne śledzenie błędów (Sentry lub OpenTelemetry), alerty dostępności oraz automatyczne kopie zapasowe PostgreSQL potwierdzone co najmniej jednym udokumentowanym testem odtworzenia.

Weryfikacja bezpieczeństwa zaczyna się od higieny poświadczeń i sieci. Audytor sprawdza wymuszone uwierzytelnianie wieloskładnikowe (MFA) na GitHubie, AWS/GCP, Cloudflare i panelach baz danych, potwierdza przechowywanie kluczy w szyfrowanych skarbcach zamiast w plikach .env w repozytorium oraz weryfikuje, czy produkcyjny PostgreSQL działa w prywatnej podsieci niedostępnej z publicznego internetu.

Wymogi regulacyjne rosną wraz z grupą docelową klientów:

• Horyzontalny B2B SaaS: Podpisane umowy powierzenia przetwarzania danych RODO (DPA), aktualna lista podprocesorów, szyfrowanie danych w spoczynku (AES-256) i w transporcie (TLS 1.3) oraz realistyczny 90-dniowy plan wdrożenia SOC 2 Typ I przez Vanta lub Drata.
• Fintech i Płatności: Nigdy nie przetwarzaj surowych numerów kart PAN na własnych serwerach; korzystaj z tokenizacji Stripe lub Adyen zgodnie z naszą listą kontrolną zgodności PCI-DSS dla startupów.
• Healthtech i Medycyna: Podpisane umowy BAA/DPA z każdym dostawcą chmury i modeli AI, pełne logowanie dostępu do danych medycznych oraz spełnienie naszych standardów oprogramowania medycznego zgodnego z HIPAA.

Filar 6: Ład danych AI i marża inferencji. Każdy kwestionariusz due diligence w latach 2026-2027 zawiera osobną sekcję poświęconą sztucznej inteligencji. Sprawdzane są trzy dowody: (1) korzystanie wyłącznie z komercyjnych punktów końcowych zero-data-retention gwarantujących, że pliki klientów nigdy nie trenują publicznych modeli; (2) izolacja zapytań wektorowych po tenant_id bezpośrednio wewnątrz funkcji SQL pgvector wraz z ochroną przed prompt injection; oraz (3) telemetria zużycia tokenów na klienta dowodząca, że koszty API nie spychają marży brutto poniżej 65%-75%.

Filar 7: Bus factor i szybkość wdrożenia nowego inżyniera. Gdyby Twój jedyny główny programista wypadł jutro z pracy na miesiąc, ile czasu potrzebowałby nowo zatrudniony senior, aby uruchomić środowisko lokalnie i bezpiecznie wdrożyć poprawkę? Jeśli przejrzyste README.md, docker compose up, syntetyczne dane testowe i zwięzłe wpisy ADR pozwalają uruchomić projekt na świeżym laptopie w mniej niż trzydzieści minut, ryzyko kadrowe natychmiast spada z czerwonego na zielone.

Raporty z audytu VC dzielą wykryte punkty na trzy koszyki: Zielony (gotowy na skalowanie), Żółty (naprawa w 90 dni po zamknięciu rundy) oraz Czerwony (warunek zawieszający przelew lub zerwanie rozmów). Brak certyfikatu SOC 2 Typ II w rundzie Seed czy skromne testy jednostkowe interfejsu trafiają do koszyka Żółtego — inwestor po prostu wpisuje je jako kamień milowy planu po inwestycji.

Ustalenia Czerwone błyskawicznie zmieniają warunki transakcji. Brak podpisanych cesji IP od dawnych podwykonawców, zahardkodowane hasła produkcyjne, brak izolacji multi-tenant czy kruchy prototyp no-code sprzedawany na prezentacji jako skalowalny system korporacyjny regularnie kończą się obniżką wyceny o 15% do 25%, zatrzymaniem $150,000 na rachunku powierniczym (escrow) albo wycofaniem komitetu inwestycyjnego. Przeprowadzenie własnego audytu próbnego cztery tygodnie przed otwarciem data roomu oddaje całą przewagę negocjacyjną w Twoje ręce.

Nie musisz wstrzymywać sprzedaży na trzy miesiące, aby bezstresowo przejść instytucjonalne technical due diligence. Skoncentrowany sprint porządkujący przed rundą zajmuje od jednego do trzech tygodni ($3,500 do $12,000 w zależności od wielkości repozytorium), gdy prowadzi go architekt znający dokładne listy kontrolne audytorów Seed i Serii A.

W pierwszym i drugim dniu uruchamiamy identyczne automatyczne skany sekretów, zależności, schematów SQL oraz uprawnień chmurowych, jakich używa zewnętrzny audytor funduszu, dostarczając priorytetową kartę ryzyk w kolorach świateł drogowych. Przez kolejne dziesięć dni roboczych Twoi programiści lub nasz seniorski zespół inżynierski usuwają wszystkie czerwone blokery, kompletują zwięzłe dziesięciostronicowe Kompendium Architektury dla Inwestora (topologia systemu, model multi-tenant, ekonomia jednostkowa AI oraz plan rekrutacji po rundzie) i ćwiczą z Tobą 60-minutową sesję pytań i odpowiedzi przed CTO funduszu.

Planujesz rundę Pre-Seed, Seed lub Serię A w najbliższym kwartale? Zamów 48-godzinny audyt przygotowawczy kodu z naszym zespołem Fractional CTO lub skontaktuj się z naszymi partnerami inżynierskimi, aby wejść do pokoju danych bez żadnych technicznych niespodzianek.