Vendor lock-in v IT: jak rozeznat smluvní pasti a čemu se vyhnout.

Vendor lock-in má dvě podoby — technickou a smluvní. Obě působí ve stejný okamžik 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: neexistující dokumentace, vlastní „proprietární framework" dodavatele, deployment přes osobní notebook jednoho člověka, hesla v hlavách lidí. U převzetí mobilní aplikace Ordinačka jsme dostali do rukou kód bez README, build, který fungoval jen v konkrétní verzi Xcode na konkrétním Macu, a admin panel v Laravel Nova, kde polovina konfigurací byla v komentářích.

Smluvní lock-in vzniká, když je smlouva napsaná tak, že vám dodavatel může zvyšovat ceny, odmítnout převzetí nebo se stáhnout, 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 „plně doplatit".

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 v praxi seděl na produkci, ke které neměl přístupy ani dokumentaci. Záchrana trvala 30 dní, ale začínali jsme s dohledáváním DNS a SSL kontaktů u třetích stran.

V naší praxi opakovaně narážíme na sedm bodů, které je nutné mít ve smlouvě explicitně. Pokud z nich dodavatel neguje byť i jeden, je to vyjednávací bod, ne ústupek.

Bod 1 — vlastnictví zdrojových kódů na straně klienta od první komitnuté řádky. Ne „po doplacení", ne „po skončení smlouvy". Standardní formulace: „Klient nabývá majetková práva ke všem dílům vzniklým v rámci plnění této smlouvy okamžikem jejich vytvoření."

Bod 2 — escrow zdrojáků u třetí strany. Pro projekty nad 1 milion Kč v rozpočtu doporučujeme escrow u nezávislého subjektu. Pokud dodavatel zmizí, escrow vám otevře přístup automaticky.

Bod 3 — povinná dokumentace jako součást deliverable. README, runbook, deployment guide, architektonický diagram. Bez dokumentace převzetí znamená měsíc reverzního inženýrství.

Bod 4 — hand-off SLA při ukončení spolupráce. Standardně 30 až 60 dní po výpovědi, kdy dodavatel musí předat přístupy, dokumentaci a odpovídat na otázky nového dodavatele.

Bod 5 — exit klauzule s definovaným procesem. Co se stane, když smlouvu ukončíte? Komu patří účty u třetích stran (DNS, monitoring, SaaS subscriptions)?

Bod 6 — neexistence proprietárních komponent bez open-source alternativy. Pokud dodavatel postaví projekt na svém vlastním nezdokumentovaném frameworku, nikdo jiný ho nepřevezme.

Bod 7 — pravidelná předávka přístupů. Ne jen „při ukončení". Klient musí mít admin přístupy k repository, k cloud účtům a k third-party službám po celou dobu spolupráce.

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 u prvních konzultací — typicky když klient přichází po neúspěšné spolupráci s jiným dodavatelem. Je to v drtivé většině případů červená vlajka.

Důvod první — proprietární framework znamená, že vás z technického dluhu nikdo nedostane. Pro převzetí potřebujete vývojáře, kteří umí stejnou technologii. Pokud je váš framework rozšířený (Spring Boot, Next.js, Laravel, .NET Core), najdete vývojáře v každé větší IT firmě. Pokud je to vlastní framework dodavatele, najdete přesně lidi z té firmy.

Důvod druhý — proprietární frameworky obvykle nemají testovací pokrytí, monitorovací nástroje a integraci s běžným ekosystémem. Zkušenost u převzetí SaaS startupu, který přicházel pre-Series A na audit, ukazovala, že kód generovaný přes nástroje typu Cursor a Lovable má vlastní druh „proprietárního lock-inu" — vygenerovaná struktura není kompatibilní s běžným refactor přístupem a vyžaduje velkou rewrite vrstvu. V projektu jsme identifikovali 14 medium a 3 high zranitelnosti, mimo jiné SQL injection ve dvou endpointech a exposed env vars v repozitáři.

Důvod třetí — proprietární framework vždy znamená vyšší cenu. Argumentem dodavatele je „rychlejší vývoj", argumentem trhu je „jediný dodavatel, který to umí".

Naše doporučení: pokud potřebujete custom řešení, postavte ho na zavedeném open-source základu. Spring Boot, Java, Next.js, .NET Core, FastAPI — všechno z naší praxe — má desítky tisíc vývojářů na trhu a žádné riziko technologické izolace.

Open-source preference v IT smlouvě neznamená „nesmí se použít komerční software". Znamená, že primární komponenty (jazyk, framework, databáze, fronta zpráv, monitoring) musí mít otevřenou alternativu nebo být přímo open-source. Komerční služby (cloud providers, SaaS) jsou v pořádku, pokud jsou snadno migrovatelné.

U projektu pro středočeskou kovovýrobu jsme primární stack postavili na .NET Core, React, PostgreSQL a OPC UA — všechno standardní open-source nebo otevřené protokoly. Pohoda jako účetní vrstva byla komerční, ale s dokumentovaným API, takže nahraditelná.

U Sportybe Europe jsme za pět let kontinuálního vývoje pracovali se Spring Boot, Java, Elasticsearch, React, Next.js, Swift a Kotlin. Žádná z těchto technologií nepředstavuje vendor lock-in — kdykoli by chtěl klient přejít k jinému dodavateli, najde si ho.

Praktická pojistka, kterou klientům doporučujeme, je explicitní seznam akceptovatelných technologií ve smlouvě. Zní to jako nadbytek, ale chrání vás v okamžiku, kdy dodavatel chce v půlce projektu „pro rychlost" přejít na svůj framework.

Pokud čtete tento článek až teď, kdy už máte projekt na proprietárním frameworku nebo dodavatele, který vám nepředá přístupy, máte tři realistické cesty.

Cesta první — vyjednat řízený exit. Zaplatíte dodavateli za hand-off (typicky 1 až 3 měsíce práce navíc), získáte dokumentaci, přístupy a postupně migrujete. Funguje, pokud dodavatel komunikuje. U Autoškoly ABC v Brně byl předchozí dodavatel rok stagnující, ale nakonec přístupy předal — dotáhnutí ERP a CRM do funkčnosti pak trvalo 6 měsíců s -40 % rozvrhování a -60 % příchozích telefonátů přes self-service portál.

Cesta druhá — paralelní rebuild. Postavíte vedle starého systému nový, postupně přesouváte data a funkce, starý odstavíte. Je to drahé (de facto stavíte projekt znovu), ale když dodavatel vůbec nereaguje, je to často jediná cesta. NemovitostiČesko byl mezikrok mezi cestou první a druhou — opuštěný projekt jsme dotáhli za 30 dní a postavili nad ním stabilní produkční prostředí s 98,5 % SLA.

Cesta třetí — fork a refactor. Pokud máte aspoň zdrojový kód (i bez dokumentace), naimportujete ho do vlastního repozitáře a postupně refactorujete pryč od proprietárních komponent.

Pokud zvažujete novou smlouvu s IT dodavatelem nebo už v lock-inu jste a chcete probrat exit, ozvěte se nám — úvodní audit smlouvy a kódu zvládneme do 5 MD a dostanete realistický odhad rizik a možností.