Vendor lock-in v IT: jak poznat závislost na dodavateli a co chtít ve smlouvě.

1. Závislost na dodavateli vzniká technicky (kód, dokumentace, nasazení) i smluvně (práva, přístupy, ukončení spolupráce).
2. Ve smlouvě o dílo na software chtějte sedm věcí: práva ke kódu s každou zaplacenou etapou, data a jejich export, dokumentaci, lhůtu pro předání, postup při ukončení, otevřené technologie a účty vedené na vaši firmu.
3. „Náš vlastní framework“ je varovný signál. Převzít ho umí jen lidé z téže firmy.
4. Pokud už závislí jste, máte tři cesty: řízený odchod, souběžnou stavbu nového systému, nebo převzetí kódu a jeho postupnou úpravu.

Vendor lock-in má dvě podoby: technickou a smluvní. Obě působí zároveň a obě bolí podobně.

Technický lock-in vzniká, když je projekt postavený tak, že ho prakticky nikdo jiný nedokáže převzít. Typické příznaky: chybějící dokumentace, vlastní uzavřený framework dodavatele, nasazování z osobního notebooku jednoho člověka, hesla v hlavách lidí. Při převzetí mobilní aplikace Ordinačka jsme dostali kód bez README, build, který fungoval jen v konkrétní verzi Xcode na konkrétním Macu, a administraci v Laravel Nova, kde polovina konfigurace byla v komentářích.

Smluvní lock-in vzniká, když je smlouva napsaná tak, že dodavatel může zvyšovat ceny, odmítnout předání nebo odejít, aniž by vám předal kompletní funkční celek. Klasické formulace: „dodavatel poskytuje licenci k užívání“, „vlastníkem zdrojových kódů zůstává dodavatel“, „v případě ukončení smlouvy musí klient projekt nejdříve plně doplatit“ bez definice, co „plně doplatit“ znamená.

U projektu NemovitostiČesko jsme přebírali aplikaci po dodavateli, který jednoduše přestal komunikovat. Klient měl licenci k užívání, ale k produkčnímu prostředí neměl přístupy ani dokumentaci. Záchrana trvala 30 dní a začínala dohledáváním kontaktů na správce DNS a SSL certifikátů u třetích stran.

Odpovězte si na osm otázek:

1. Máte přístup ke zdrojovému kódu všeho, co jste už zaplatili?
2. Jsou doména, DNS, hosting a účty u služeb třetích stran vedené na vaši firmu?
3. Existuje dokumentace, podle které by systém nasadil někdo cizí?
4. Umí systém nasadit víc než jeden člověk?
5. Stojí systém na rozšířených technologiích, které zná víc dodavatelů?
6. Dává vám smlouva právo kód upravovat a svěřit úpravy jinému dodavateli?
7. Říká smlouva, co a do kdy dodavatel předá při ukončení spolupráce?
8. Umíte kdykoli vyexportovat svá data v běžném formátu?

Tři a více odpovědí „ne“ znamenají, že výměna dodavatele bude drahá. Začněte prvními dvěma body, ty jdou vyřešit hned.

Opakovaně narážíme na sedm bodů, které má smlouva o dílo na software obsahovat výslovně. Pokud dodavatel kterýkoli z nich odmítne, je to bod k vyjednávání, ne k ústupku.

1. Práva ke zdrojovým kódům přecházejí na klienta zaplacením. Nejlépe průběžně: s každou uhrazenou etapou získáte práva k tomu, co jste zaplatili, a kód dostanete do svého repozitáře. Pozor na smlouvy, kde práva přecházejí až po „úplném doplacení“ bez jasné definice, nebo kde zůstávají dodavateli natrvalo a vy máte jen licenci k užívání.
2. Data patří klientovi a jdou kdykoli vyexportovat. Smlouva má říkat, že data v systému jsou vaše a že je dostanete v běžném formátu (například CSV, JSON nebo export databáze) kdykoli během spolupráce i po jejím skončení. Samotný zdrojový kód bez dat provoz neobnoví.
3. Dokumentace jako povinná součást dodávky. README, provozní příručka (runbook), postup nasazení, schéma architektury. Bez dokumentace znamená převzetí měsíc reverzního inženýrství.
4. Závazná lhůta pro předání při ukončení spolupráce. Obvykle 30 až 60 dní po výpovědi, během kterých dodavatel předá přístupy a dokumentaci a odpovídá na otázky nového dodavatele.
5. Výstupní klauzule s popsaným postupem. Co se stane, když smlouvu ukončíte? Komu patří účty u třetích stran (DNS, monitoring, předplatné služeb)?
6. Žádné uzavřené komponenty bez open-source alternativy. Pokud dodavatel postaví projekt na vlastním nezdokumentovaném frameworku, nikdo jiný ho nepřevezme.
7. Účty a přístupy vedené na klienta. Doména, DNS, cloud a služby třetích stran mají být od začátku vedené na vaši firmu a vy k nim máte mít administrátorský přístup. Ke zdrojovému kódu dostáváte přístup průběžně, s každou zaplacenou etapou, ne až „při ukončení“.

Větu „postavíme to na našem vlastním frameworku, který je rychlejší a flexibilnější než cokoli na trhu“ slyšíme občas na prvních konzultacích, typicky když klient přichází po neúspěšné spolupráci s jiným dodavatelem. V drtivé většině případů je to varovný signál.

Proprietární (uzavřený) framework je takový, který vyvinul a ovládá jediný dodavatel a ke kterému nemá nikdo jiný dokumentaci ani zkušenosti.

Za prvé: z technického dluhu vás nikdo jiný nedostane. Pro převzetí potřebujete vývojáře, kteří umějí stejnou technologii. Pokud stavíte na rozšířeném frameworku (Spring Boot, Next.js, Laravel, .NET Core), najdete je v každé větší IT firmě. Pokud je to vlastní framework dodavatele, najdete je jen u něj.

Za druhé: vlastní frameworky obvykle nemají testy, monitorovací nástroje ani napojení na běžný ekosystém.

Za třetí: vlastní framework zpravidla znamená vyšší cenu. Argumentem dodavatele je „rychlejší vývoj“, argumentem trhu je „jediný dodavatel, který to umí“.

Naše doporučení: pokud potřebujete řešení na míru, postavte ho na zavedeném open-source základu. Spring Boot, Java, Next.js, .NET Core, FastAPI (všechno z naší praxe) mají na trhu desítky tisíc vývojářů a riziko technologické izolace je u nich minimální.

Ano. Při auditu SaaS startupu před investičním kolem Series A se ukázalo, že kód generovaný nástroji typu Cursor a Lovable vytváří vlastní druh závislosti: vygenerovaná struktura se nedá běžně upravovat a velkou část je nutné přepsat. V projektu jsme našli 14 zranitelností střední a 3 vysoké závažnosti, mimo jiné SQL injection ve dvou endpointech a proměnné prostředí vystavené v build artefaktu.

Pokud aplikaci stavíte s pomocí AI nástrojů, nechte si kód před dalším rozvojem nezávisle prověřit. Podrobněji to popisujeme u služby AI audit vibe-coded aplikací.

Preference open-source ve smlouvě neznamená, že se nesmí použít komerční software. Znamená, že hlavní komponenty (jazyk, framework, databáze, fronta zpráv, monitoring) mají být open-source nebo mít otevřenou alternativu. Komerční služby (cloud, SaaS) jsou v pořádku, pokud se z nich dá snadno migrovat.

U projektu pro středočeskou kovovýrobu jsme hlavní technologie postavili na .NET Core, Reactu, PostgreSQL a OPC UA, tedy na standardním open-source a otevřených protokolech. Účetní vrstvu tvořila komerční Pohoda, ale s dokumentovaným API, takže je nahraditelná.

U Sportybe Europe jsme za pět let nepřetržitého vývoje pracovali se Spring Bootem, Javou, Elasticsearchem, Reactem, Next.js, Swiftem a Kotlinem. Žádná z těchto technologií nepředstavuje vendor lock-in. Kdyby chtěl klient přejít k jinému dodavateli, najde ho.

Praktická pojistka, kterou klientům doporučujeme, je výslovný seznam přijatelných technologií ve smlouvě. Zní to jako zbytečnost, ale chrání vás ve chvíli, kdy chce dodavatel v půlce projektu „pro rychlost“ přejít na vlastní framework.

Pokud tenhle článek čtete až ve chvíli, kdy máte projekt na uzavřeném frameworku nebo dodavatele, který vám nepředá přístupy, máte tři realistické cesty.

1. Řízený odchod. Zaplatíte dodavateli za předání (typicky 1 až 3 měsíce práce navíc), získáte dokumentaci a přístupy a postupně migrujete. Funguje, pokud dodavatel komunikuje. U Autoškoly ABC v Brně předchozí dodavatel rok stagnoval, ale přístupy nakonec předal. Dotažení ERP a CRM do funkčního stavu pak trvalo 6 měsíců. Po nasazení klesl čas na rozvrhování o 40 % a počet telefonátů na recepci o 60 %, hlavně díky samoobslužnému portálu.
2. Souběžná stavba nového systému. Vedle starého systému postavíte nový, postupně do něj přesouváte data a funkce a starý odstavíte. Je to drahé, protože projekt stavíte znovu, ale když dodavatel vůbec nereaguje, bývá to jediná cesta. NemovitostiČesko byl případ na pomezí první a druhé cesty: opuštěný projekt jsme dotáhli za 30 dní a postavili nad ním stabilní produkční prostředí s 98,5 % SLA.
3. Převzetí kódu a postupná úprava. Pokud máte aspoň zdrojový kód (i bez dokumentace), přenesete ho do vlastního repozitáře a postupně v něm nahrazujete uzavřené komponenty.

Zvažujete novou smlouvu s IT dodavatelem, nebo už v lock-inu jste a chcete probrat odchod? Ozvěte se nám. Úvodní audit smlouvy a kódu zvládneme v rozsahu do 5 člověkodní a dostanete realistický odhad rizik a možností. Jak takové převzetí probíhá, popisujeme u služby Převzetí vývoje a v článku Převzetí vývoje softwaru: pět signálů a prvních 30 dní.