Technologická due diligence IT vývojářské firmy

O transakci

Výchozí situace

Strategický investor nedávno vstoupil do IT vývojářské firmy, která měla vlastní softwarový produkt. Standardní finanční a právní due diligence proběhla v průběhu transakce. Technologická DD se ale z časových nebo organizačních důvodů v tu dobu nekonala — jedna z věcí, které se často „odloží na později”.

Po dokončení transakce si investor uvědomil, že potřebuje nezávislé zmapování reálného technologického stavu — ne aby rozbil transakci, ale aby věděl, s čím reálně pracuje. Je produkt z technického pohledu tak zdravý, jak se na obchodních schůzkách prezentoval? Kde jsou skryté náklady, které se projeví v dalších 12–24 měsících? Jaká je reálná schopnost produkt škálovat, přidávat funkce a přivádět nové zákazníky?

Vedení cílové firmy s DD spolupracovalo otevřeně, což pro tento typ post-transakční analýzy není samozřejmé — ale ukázalo se, že samo vedení tušilo, že některé oblasti nejsou v ideálním stavu, a potřebovalo je mít „úředně” pojmenované, aby s nimi mohlo dělat.

Co bylo v rozsahu

• Architektura produktu — stav kódové báze, použité technologie, zralost řešení
• Infrastruktura a provozní stránka — hostingové prostředí, deployment, monitoring, disaster recovery
• Vývojové procesy — CI/CD, code review, release management
• QA a testování — pokrytí testy, procesy kvality, defect management
• Lidé a organizace — klíčové role, závislost na jednotlivcích (bus factor), struktura týmu
• Dodavatelé a závislosti — externí partneři, open-source komponenty, vendor lock-in
• Bezpečnost a compliance — strategická úroveň, ne technický pentest
• IP a licenční stránka — kdo vlastní kód, licenční situace komponent
• Produktová roadmap a technický dluh — co je v backlogu, co se v něm skrývá

Jak DD probíhala

DD trvala 5 týdnů včetně všech výstupů a prezentací. Protože šlo o post-investiční analýzu, nebyla časově tak napjatá jako typická pre-transakční DD.

Fáze 1 — Přístup a podklady (týden 1)

Kickoff s vedením cílové firmy, CTO a klíčovými lidmi z vývoje. Přístup k dokumentaci, kódové bázi, monitorovacím nástrojům a reporting systémům. Vytvoření struktury rozhovorů a pozorování.

Fáze 2 — Studium a analýza (týdny 2–3)

Prošel jsem kódovou bázi a architekturu produktu, vývojové procesy (reálnou CI/CD pipeline, ne jen tu „na papíře”), provozní data (incidenty, dostupnost, výkon a nákladovou strukturu hostingu), a vedl rozhovory s klíčovými vývojáři a QA o tom, kde se tvoří technický dluh a kde se bojí nejvíc.

Fáze 3 — Konsolidace zjištění (týden 4)

Zjištění jsem strukturoval do tří kategorií podle urgence a dopadu:

• Red flags — zjištění s vysokým dopadem, ke kterým je potřeba se postavit v horizontu měsíců
• Yellow flags — rizika, která zatím nebolí, ale bez adresování v 12–24 měsících se projeví
• Positive findings — oblasti, ve kterých bylo řešení v dobré kondici

Fáze 4 — Draft, diskuse, finalizace (týden 5)

Pracovní verzi jsem nejprve sdílel s vedením cílové firmy — aby měli možnost reagovat, doplnit kontext, případně zpochybnit interpretaci. Po této fázi jsem zjištění prezentoval investorovi s finálním reportem a doporučeními.

Klíčová zjištění

Architektura a technologický stack

Klíčové části produktu běžely na starším technologickém stacku s omezenou dlouhodobou udržitelností. Modernizace části komponent byla potřebná do 12–24 měsíců — jinak by rostly potíže s náborem vývojářů a s dostupností aktuálních knihoven. Architektura celkově byla logická a srozumitelná, ale některé moduly měly vysoký technický dluh.

Závislosti a vendor lock-in

Existovala významná závislost na konkrétních open-source komponentách, u kterých se zpomalil vývoj komunity. Pro některé specializované funkce firma využívala dodavatele bez zpracovaného exit plánu — výpadek dodavatele by vedl k několikaměsíční rekonstrukci. Bus factor u několika kritických částí produktu — konkrétní znalost držely 1–2 osoby bez dostatečné dokumentace.

Provozní stránka

Disaster recovery procedury byly deklarované, ale v posledních 18 měsících netestované. Observability (monitoring, tracing, logging) byla nekonzistentní — pro některé části produktu dobrá, pro jiné minimální. Reakce na incidenty byla funkční, ale postavená na hrdinství konkrétních lidí, ne na procesu.

Kvalita a testování

QA bylo významně poddimenzované vzhledem k velikosti produktu a frekvenci releasů. Test coverage byla nízká a nerovnoměrná. Regresní testy byly převážně manuální, což zpomalovalo release cadence. Defekty, které se dostávaly k zákazníkům, často souvisely s nedostatečným automatizovaným testováním.

Pozitivní zjištění

Celkové doménové know-how bylo silné — tým rozuměl problému, který produkt řeší. IP a licenční situace byla čistá — firma si evidovala vlastnictví kódu, open-source licence byly kompatibilní. Kultura týmu byla pozitivní a motivovaná. Compliance stránka byla v pořádku.

Co klient (investor) dostal

• Executive summary pro investiční výbor — klíčová zjištění a strategická doporučení na 2–3 stranách
• Detailní report strukturovaný podle oblastí, s konkrétními zjištěními a jejich dopady
• Registr red flagů a yellow flagů s prioritizací a doporučenou dobou k adresování
• Odhad potřebných investic v horizontu 12–24 měsíců — modernizace stacku, posílení QA, observability, exit plány dodavatelů
• Návrh organizačních změn — zejména v oblasti QA a knowledge management
• Prezentace pro vedení investora i cílové firmy

Jaký to mělo přínos

Výstup DD byl použit jako strategický vstup pro nastavení dalšího vývoje firmy. Konkrétně vedl k:

• Upravené roadmapě — prioritizace modernizace paralelně s novými funkcemi
• Personálním změnám — cílené posílení týmu, zejména v oblasti QA (navýšení kapacit, zavedení automatizace)
• Modernizaci provozního stacku — postupná migrace klíčových komponent, přebudování observability
• Zavedení jednotného standardu monitoringu, tracingu a loggingu napříč produktem

Investor získal realistický pohled, s jakým produktem a organizací reálně pracuje. Místo pocitu „koupili jsme něco, co má skryté problémy” měl strukturovaný plán, co s tím udělat a v jakém pořadí. Vedení cílové firmy dostalo mandát k interním změnám, které sama dlouho chtěla, ale neměla „externí tlak”, který by je prosadil na úroveň priority.

Paradoxně byla post-transakční DD ještě cennější než klasická předtransakční — transakce už proběhla, takže zjištění neovlivňovala cenu, ale přímo vedla k akci a realizaci. Nebyla to DD, která se schová do šuplíku. Byla to DD, která se v průběhu dalších 12 měsíců systematicky proškrtávala bod za bodem.

Poznámka z praxe

Tento projekt potvrdil, že technologická DD dává smysl i po dokončení transakce. V IT vývojářských firmách s vlastním produktem tvoří technologie páteř hodnoty — a v době transakce bývá tlak na čas, takže se DD buď zkracuje, nebo odkládá. Investor, který se později rozhodne nezávisle posoudit, s čím vlastně pracuje, získá nejen přehled, ale i akční plán. Důležitá byla i ochota vedení cílové firmy ke spolupráci — post-transakční DD, kterou vedení vnímá jako kontrolu „proti sobě”, je mnohem těžší než DD, kde vedení samotné vidí hodnotu v pojmenování reálného stavu.

O kterou službu šlo

Klasická technologická due diligence, byť provedená v méně typickém post-transakčním formátu. V katalogu služeb je specifikován rozsah a průběh tohoto typu projektu.