Technický audit pro Series A: co si investor reálně přečte.

Investor v rané fázi má dvě paralelní starosti — produktovou a technickou. Produktovou (PMF, retence, růst, jednotková ekonomika) si umí ohodnotit interní tým fondu. Technickou si nezávisle objedná, protože sám nemá kapacitu lézt do kódu.

Cíl auditu z pohledu investora je tří úrovní. První — ověřit, že to, co zakladatelé tvrdí, kód skutečně dělá. Druhá — odhalit rizika, která mohou v horizontu 12 měsíců vést k incidentu (security breach, data loss, scaling kolaps). Třetí — odhadnout technický dluh a refactor cost, který bude součástí post-money plánu.

Pro startup pre-Series A, který jsme auditovali na konci roku 2024, byl trigger investorské zadání: „Kód je generován převážně přes Cursor a Lovable, potřebujeme nezávislé ověření, že to není riziko před investicí." Audit trval 4 týdny, následný refactor další 4. Výstupem byl due diligence dokument plus AI roadmapa, kterou zakladatelé použili v investorském decku.

U AiLuvia, českého AI startupu připravujícího se na mezinárodní launch, jsme prošli paralelní cestou — stabilizace mobilní aplikace ve čtyřech fázích, od build errors a crypto knihoven přes UI/UX po publikaci na App Store a Google Play. Tohle nebyl přímo investorský audit, ale výstupem byla aplikace, která mohla projít DD bez vážných nálezů.

Technická due diligence pro Series A obvykle pokrývá šest oblastí. Investor nemusí dostat všechny v hloubce — záleží na velikosti checku — ale alespoň povrchový průchod každou.

Oblast 1 — architektura a stack. Investor chce vědět, jestli stack škáluje na 10× a 100× současné zátěže. Otázky: monolit nebo microservices, kde leží stateful komponenty, jak se škáluje databáze, je něco kritické na single-point-of-failure. Pro běžnou Series A není problém být na monolitu — problém je nemít plán, jak ho rozdělit, až bude třeba.

Oblast 2 — security. Tady padá nejvíce valuací. U auditovaného B2C SaaS startupu jsme identifikovali 14 medium a 3 high zranitelnosti, včetně SQL injection ve dvou endpointech, exposed env vars v repozitáři a chybějící rate limiting na autentizačních endpointech. Investor takový nález dostane do shrnutí na první straně.

Oblast 3 — data a privacy. GDPR, kde jsou uložená osobní data, šifrování at-rest a in-transit, retention policy, audit logy. Pro B2C v EU je to compliance must-have.

Oblast 4 — AI/ML komponenty (pokud jsou). Eval framework, prompt versioning, monitoring halucinací v produkci, datová bezpečnost pro fine-tuning, vendor dependency. U vibe-coded AI komponent vidíme velmi často, že eval set neexistuje a jediný „test" je, že to nepadá.

Oblast 5 — IP a licence. Komu patří kód, jaké open-source licence jsou v dependencích, jsou GPL komponenty v komerčním produktu (problém), je copyright assignment jasný od všech přispěvatelů včetně bývalých.

Oblast 6 — tým a procesy. Bus factor (kolik lidí může zítra odejít, aniž by se projekt zastavil), code review proces, CI/CD, incident response, on-call.

Některé nálezy v DD jsou kosmetické — opravíte je za týden a investor je akceptuje. Některé jsou cap-tabling material — investor je použije k vyjednání nižší valuace nebo silnějších termsheet podmínek. Pojmenuju ty, které vidíme nejčastěji.

Vibe-coded codebase bez auditu. Pokud jste 80 % kódu vygenerovali přes Cursor, Lovable nebo v0 a nikdo to nezreviewoval, dostanete v DD červený praporek. Není to o tom, že vibe-coding je špatný — je to o tom, že bez auditu nikdo neví, co tam je. U auditovaného SaaS startupu byl ale větší problém než samotná generovaná architektura konkrétní lapsus: SQL injection vznikl v ručně dopisovaném endpointu, ne v generované části.

Žádné automated testy. Investor neočekává 80% pokrytí. Očekává, že existuje testovací framework, alespoň smoke testy nejdůležitějších flow a CI, který je spouští. „Testujeme manuálně" je v DD ekvivalent „neví, co máme".

No monitoring, no alerting. Pokud production běží bez logování, metrik a alertů, investor vidí budoucí incident bez schopnosti reakce.

Kritická závislost na třetí straně. Když 70 % funkčnosti běží přes jeden API klíč externí služby a smlouvu nemáte, investor počítá riziko price gouging.

Hardcoded secrets. Klíče v repozitáři jsou stále jeden z nejčastějších nálezů. Po objevení je standardní postup rotace všech klíčů, ne jen smazání z gitu.

Pokud investor objednal audit a vy víte, že tam něco bude, máte dvě možnosti — buď čekat a doufat, nebo proaktivně audit doprovodit refactor plánem.

Refactor plán je v praxi to, co rozhoduje. U auditovaného SaaS startupu jsme po identifikaci 14 medium + 3 high zranitelností okamžitě zpracovali 4týdenní refactor harmonogram s konkrétními milestony — týden 1 odstranění SQL injection, týden 2 přesun secrets do vault a rotace, týden 3 implementace rate limitů a CSRF protection, týden 4 audit logy a monitoring. Investor tento dokument dostal jako přílohu DD a místo „14 medium + 3 high" viděl „14 medium + 3 high s plánem opravy v 4 týdnech".

Druhá věc, která pomáhá, je transparentnost. Když v DD něco zatajíte a investor to najde sám, valuace klesne víc, než kdybyste to sami pojmenovali a vysvětlili. „Víme o této díře, máme plán, opravíme ji do data X" je z investorského pohledu silnější než „nic tam není" a následný objev.

Třetí věc je realistický timeline. Refactor 4 až 8 týdnů je na Series A audit obvyklý — investor počítá s tím, že část jeho check bude na technický dluh. 6 měsíců refactoru už je problém, protože to znamená pauzu ve features.

Komunikace výsledků auditu s investorem je svým způsobem důležitější než samotný audit. Tři principy, které v naší praxi fungují.

Princip první — pojmenování závažnosti vlastními slovy. Pokud audit obsahuje 17 nálezů, ne všech 17 je stejně závažných. Klasifikace na critical / high / medium / low s konkrétním vysvětlením, proč daný nález má danou závažnost, dává investorovi navigaci. „SQL injection v autentizačním endpointu je critical, protože umožňuje extrakci uživatelských dat" je víc než „nález XYZ".

Princip druhý — odpověď na nález ve stejném dokumentu. Když refactor plán je v jiném PDF než nález, investor je nespáruje. Společný dokument, kde za každým nálezem následuje plán mitigace s odpovědným člověkem a deadlinem, snižuje psychologický dopad zhruba o polovinu.

Princip třetí — eskalace toho, co opravdu nelze vyřešit. Pokud nějaký nález je strukturální (např. databázová architektura, která neunese 10× zátěž bez rewrite), nezakrývejte ho. Pojmenujte ho jako součást post-money plánu — investor s tím počítá, pokud o tom ví dopředu.

Pokud připravujete startup na Series A nebo Series B a chcete proaktivní DD audit dřív, než ho objedná investor, ozvěte se nám — předauditní průchod kódu, security a AI komponent zvládneme za 3 až 5 týdnů a dostanete dokument, který můžete přiložit přímo k investorskému decku.