---
title: "Techniczna Lista Kontrolna Due Diligence dla Startupów"
slug: "technical-due-diligence-checklist-seed-startups"
url: "https://mvp-development.io/pl/blog/technical-due-diligence-checklist-seed-startups"
type: post
lang: pl
date: "2026-11-07"
last_modified: "2026-11-07"
version: "1.0"
summary: "Przejdź audyt VC Pre-Seed, Seed i Serii A z naszą 7-filarową listą kontrolną technical due diligence: własność IP, CI/CD, bezpieczeństwo RODO i AI."
author: "MVP Development"
tags: ["techniczna lista kontrolna due diligence", "technical due diligence startup", "audyt techniczny vc seed", "audyt kodu przed rundą finansowania", "prawa majątkowe ip kod źródłowy", "architektura multi tenant saas"]
use:
  training: allow
  rag: allow
  embedding: allow
attribution: required
---

# Techniczna Lista Kontrolna Due Diligence dla Startupów

## Co naprawdę sprawdzają audytorzy VC w latach 2026 i 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](https://mvp-development.io/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](https://mvp-development.io/custom-software), czy przejąłeś wczesny kod po agencji.

Żaden startup na etapie Seed nie posiada infrastruktury wielkiego banku. Jeśli sam pokażesz audytorowi krótką listę trzech świadomych uproszczeń podjętych dla szybszej walidacji przychodów wraz z dwutygodniowym kosztem ich spłaty po rundzie, zyskasz wysoką ocenę za dojrzałość inżynierską.

## Filary 1 i 2: Czysty łańcuch praw IP oraz pułapki licencji open source

**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](https://mvp-development.io/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.

## Filar 3: Architektura multi-tenant, higiena bazy danych i zapas 10x

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](https://mvp-development.io/blog/multi-tenant-architecture-saas-mvp)? 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](https://mvp-development.io/blog/mvp-security-scalability-guide), aby wcześnie wyłapać ograniczenia.

### 7-filarowa karta oceny technical due diligence VC według etapu finansowania

| Filar audytu | Próg zaliczenia Pre-Seed | Standard rundy Seed | Wymóg Serii A | Czerwona flaga blokująca deal |
| --- | --- | --- | --- | --- |
| 1. Własność IP i Chmury | Umowy IP founderów/devów; firmowy GitHub | 100% zgodności commitów z umowami; własny root chmury | Pełny audyt IP + zgłoszenia znaków towarowych | Były wspólnik lub agencja posiada GitHub / AWS root |
| 2. Licencje Open Source | Brak zależności AGPL w rdzeniu systemu | Czysty skan SBOM (MIT / Apache-2.0) | Bramka licencyjna w CI + spisana polityka OSS | Główny silnik biznesowy oparty na kodzie AGPLv3 |
| 3. Skala Multi-Tenant | Jedna baza z czystymi kluczami tenant_id | PostgreSQL RLS, indeksy złożone, kolejki async | Testy obciążeniowe 10x + gotowość replik odczytu | Ręczne kopie bazy na klienta lub wycieki między firmami |
| 4. CI/CD i Tempo Wdrożeń | Wdrożenia GitHub Actions + podstawowe smoke testy | Chroniony main, code review PR, testy auth/płatności | Wdrożenia bez przestojów, rollback <15m, staging | Ręczne wgrywanie zmian przez SSH/FTP na produkcję |
| 5. Bezpieczeństwo i RODO | Zarządzane auth, HTTPS, zero sekretów w gicie | Wszędzie MFA, menedżer sekretów, umowy RODO, backupy | SOC 2 Typ I/II, raport z pentestów, HIPAA/PCI | Hasła jawnym tekstem, wyciek kluczy AWS, brak kopii bazy |
| 6. Ład AI i Marża Brutto | Komercyjne API LLM bez retencji danych | Zapory prompt-injection, maskowanie PII, limity kwot | Ewaluacje w CI, umowy BAA/DPA, marża brutto >75% | Trenowanie modeli na plikach klientów bez zgody |
| 7. Bus Factor i Dokumentacja | Czytelne README + start lokalny w <30 min | Rejestr ADR, min. 2 inżynierów zna główne moduły | Ułożone zespoły, instrukcje dyżurne, metryki DORA | Jeden zewnętrzny programista trzyma wszystkie dostępy |

## Filar 4: Potoki CI/CD, automatyczne bramki testowe i tempo wdrożeń

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.

## Filar 5: Bezpieczeństwo, zarządzanie sekretami oraz SOC 2 / RODO / HIPAA

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](https://mvp-development.io/blog/pci-dss-compliance-checklist-startups).
- **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](https://mvp-development.io/blog/hipaa-compliant-healthcare-software).

Audytorzy techniczni uruchamiają `gitleaks` lub `trufflehog` na całej historii repozytorium w pierwszych dziesięciu minutach badania. Jeśli programista osiem miesięcy temu przypadkiem wrzucił klucz AWS lub hasło bazy i usunął je w kolejnym commicie, poświadczenie jest spalone: natychmiast dokonaj rotacji klucza i wyczyść historię.

## Filary 6 i 7: Ład danych AI, marża jednostkowa oraz bus factor zespołu

**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.

## Karta oceny audytu: żółte zalecenia kontra powody obniżenia wyceny

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.

### Plan 3-tygodniowego sprintu naprawczego przed otwarciem data roomu VC

| Tydzień sprintu | Naprawiane filary | Kluczowe działania inżynierskie | Gotowy dokument do Data Roomu |
| --- | --- | --- | --- |
| Tydzień 1: IP, Sekrety i Chmura | Filary 1, 2 i 5 | Zestawienie autorów gita z umowami IP, gitleaks + rotacja kluczy, skan SBOM, blokada MFA/IAM | Arkusz czystości praw IP oraz czysty raport licencyjny SBOM |
| Tydzień 2: Izolacja, CI/CD i Backupy | Filary 3 i 4 | Włączenie PostgreSQL RLS, testy auth/tenant, blokada gałęzi main, próbne odtworzenie bazy | Zrzut potoku CI/CD, protokół odtworzenia kopii i testy RLS |
| Tydzień 3: Marża AI i Pakiet Inwestorski | Filary 6 i 7 | Potwierdzenie API zero-retention, limity kwotowe na klienta, diagram C4 oraz spisanie ADR | Pakiet Architektury dla Inwestora (diagram C4, ADR, plan 12M) |

## Jak przeprowadzić 1- do 3-tygodniowy sprint naprawczy przed rundą

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](https://mvp-development.io/fractional-cto) lub [skontaktuj się z naszymi partnerami inżynierskimi](https://mvp-development.io/contact), aby wejść do pokoju danych bez żadnych technicznych niespodzianek.

## FAQ

**Ile czasu trwa badanie technical due diligence w rundzie Seed lub Serii A?**

Na etapie Pre-Seed weryfikacja trwa zwykle od 3 do 5 dni roboczych i obejmuje 60-minutowy przegląd architektury oraz wyrywkową kontrolę repozytorium. W rundzie Seed badanie zajmuje od 1 do 2 tygodni (umowy IP, historia GitHuba, bezpieczeństwo chmury i skalowalność), natomiast w Serii A trwa od 2 do 4 tygodni i często obejmuje skany SBOM oraz zewnętrzne testy penetracyjne.

**Jakie są najczęstsze powody zerwania inwestycji podczas audytu technicznego?**

Cztery najgroźniejsze blokery to brak podpisanych umów przeniesienia praw IP od byłych wspólników lub wczesnych freelancerów, wirusowy kod AGPLv3 zaszyty w głównym silniku produktu, luki pozwalające jednemu klientowi odczytać dane innej firmy oraz deklarowanie własnej technologii AI, która okazuje się niezabezpieczoną nakładką na prompt z ujemną marżą.

**Czy korzystanie z kodu generowanego przez AI (Cursor, Copilot, Claude) szkodzi podczas audytu VC?**

Nie — nowoczesne fundusze oczekują, że szybkie zespoły wspomagają się narzędziami AI. Audytu nie przechodzi natomiast bezrefleksyjnie wygenerowany kod spaghetti, w którym nikt w firmie nie rozumie schematu bazy danych, endpointy API nie sprawdzają uprawnień ról, a płatności i izolacja klientów nie mają żadnych testów automatycznych.

**Czy przed zamknięciem rundy Seed musimy posiadać gotowy certyfikat SOC 2 Typ II?**

Przed zamknięciem rundy Seed niemal nigdy, chyba że sprzedajesz bezpośrednio do dużych banków. Audytorzy Seed wymagają solidnej higieny podstawowej — powszechnego MFA, szyfrowanych sekretów, przetestowanych kopii zapasowych, izolacji PostgreSQL oraz umów RODO — uzupełnionej wiarygodnym planem dojścia do SOC 2 Typ I w 90-180 dni po finansowaniu.

**Czy przejdziemy due diligence funduszu VC, jeśli nasze MVP zbudował zewnętrzny software house?**

Tak, pod warunkiem spełnienia trzech twardych zasad: Twoja spółka posiada 100% majątkowych praw autorskich IP na mocy podpisanej umowy, wszystkie repozytoria oraz konta chmurowe należą bezpośrednio do Twojej firmy, a wewnętrzny lider techniczny lub Fractional CTO w pełni rozumie architekturę i zarządza dalszą mapą drogową.

**Ile kosztuje próbny audyt technical due diligence przed rozpoczęciem fundraisingu?**

Niezależny 48- do 72-godzinny audyt kodu źródłowego i architektury chmurowej zakończony kartą oceny ryzyk kosztuje zazwyczaj od $2,500 do $5,000. Jeżeli przed otwarciem data roomu potrzebny jest dodatkowo praktyczny 2- do 3-tygodniowy sprint naprawczy obejmujący izolację multi-tenant, CI/CD, sekrety i dokumentację inwestorską, budżet wynosi zwykle od $6,000 do $14,000.