Proč je smlouva při společném vývoji produktu zásadní
U společného vývoje produktu se typicky spojují dvě nebo více stran: jedna přináší know-how, druhá technologii, třetí obchodní kanál nebo data. Právě proto je smlouva důležitější než u běžného dodavatelského vztahu. Neřeší jen „kdo co udělá“, ale hlavně kdo vlastní výsledek, kdo může produkt dál rozvíjet a kdo nese riziko.
V praxi vznikají spory nejčastěji kolem tří oblastí: duševní vlastnictví, rozhodování o změnách a rozdělení výnosů. Pokud se to nepopíše předem, může i úspěšný MVP skončit blokací dalšího vývoje. Z pohledu řízení projektu je proto vhodné smlouvu nastavit ještě před prvním commitem do repozitáře nebo před předáním prvních dat do testovacího prostředí.
U menších projektů se často podceňuje i dokumentace. Přitom už základní evidence verzí, předávacích protokolů a rozhodnutí z jednání výrazně snižuje riziko sporů. V ideálním případě smlouva navazuje na projektový plán, backlog a jasně definované milníky.
Jak přesně vymezit předmět spolupráce
Základní chybou je napsat, že strany „spolupracují na vývoji produktu“, bez dalšího upřesnění. Taková formulace je právně i provozně slabá. Předmět smlouvy musí popisovat co se vyvíjí, v jakém rozsahu, s jakým cílem a v jaké kvalitě.
Dobrá praxe je rozdělit popis do čtyř částí:
- funkční rozsah – například webová aplikace pro objednávky, mobilní aplikace, interní nástroj nebo hardware prototyp,
- technologický stack – například Next.js, WordPress, Laravel, API integrace, cloudové služby,
- cílové výstupy – MVP, beta verze, produkční verze, dokumentace, testy,
- kritéria dokončení – akceptační kritéria, výkonové parametry, bezpečnostní požadavky, kompatibilita.
Praktický příklad: Pokud dvě firmy vyvíjejí SaaS produkt, smlouva by měla uvést, že výsledkem je například „funkční webová aplikace pro správu rezervací s administrací, API a přístupem pro 500 aktivních uživatelů“. Tím se zabrání tomu, aby jedna strana později tvrdila, že součástí bylo i další analytické moduly nebo nativní mobilní aplikace, které ve smlouvě vůbec nebyly.
Duševní vlastnictví, licence a práva k výstupům
Nejcitlivější část smlouvy je obvykle vlastnictví kódu, designu, dokumentace, databáze, brandingu a know-how. U společného vývoje je potřeba rozlišit, co je předané vstupní IP a co je nově vytvořený výsledek. Bez toho vzniká právní šedá zóna, zejména pokud se do vývoje zapojí externí vývojáři nebo agentura.
V praxi se používají tři modely:
- společné vlastnictví – obě strany vlastní výsledek společně, ale musí být přesně určeno, kdo smí co dělat,
- vlastnictví jedné strany – jedna strana vlastní celý výstup a druhá dostává licenci nebo podíl na výnosech,
- licenční model – vlastnictví zůstává autorovi nebo vývojáři, druhá strana získá časově či územně omezenou licenci.
U software je důležité uvést i režim open-source komponent. Například použití knihoven s licencí MIT bývá bezproblémové, ale GPL nebo AGPL může ovlivnit možnost komerčního uzavření produktu. Ve smlouvě proto doporučuji vyžadovat seznam použitých open-source balíčků a pravidla jejich schvalování.
Jestli se produkt opírá o data, je nutné řešit i práva k datovým sadám, trénovacím datům pro AI nebo exportům z CRM. U AI funkcí je zvlášť důležité určit, zda může jedna strana data použít pro další modely, benchmarky nebo marketingové účely. Bez takového ujednání může vzniknout spor i u zdánlivě „neutrálních“ podkladů.
Řízení projektu, změny a odpovědnost za dodávky
Dobrá smlouva není jen právní dokument, ale i nástroj projektového řízení. Musí říkat, kdo rozhoduje o prioritách, jak se schvalují změny a co se stane při prodlení. U vývoje produktu je změnové řízení klíčové, protože scope creep je běžný problém a bez pravidel se projekt snadno prodraží o desítky procent.
Vhodné je nastavit tento mechanismus:
- jasný seznam rolí a odpovědností,
- harmonogram milníků s termíny,
- pravidla pro schvalování změn přes change request,
- definici akceptace předání,
- sankce nebo nápravné lhůty při nesplnění termínu.
Pokud například tým mění backendovou architekturu kvůli výkonu, smlouva by měla určit, zda jde o součást původního zadání, nebo o novou práci navíc. Praktická forma je navázat změny na ticketovací systém, například Jira nebo Linear, a ve smlouvě odkázat na to, že změna je platná až po písemném schválení oběma stranami.
Za velmi užitečné považuji i ustanovení o komunikaci: kdo je kontaktní osoba, jak často probíhají status meetingy, kde se ukládá dokumentace a jak se potvrzují rozhodnutí. U menších týmů stačí týdenní reporting, u větších projektů je vhodné stanovit měsíční steering meeting a sdílený prostor v Notion, Confluence nebo Google Workspace.
Finance, odměna a rozdělení výnosů
Finanční část bývá zdrojem největších nedorozumění, protože „společný vývoj“ může znamenat úplně jiný model příjmů. Někdy jde o fixní cenu za část práce, jindy o podíl na tržbách, equity nebo hybridní model. Smlouva musí přesně určit, za co se platí, kdy vzniká nárok na odměnu a z čeho se počítá podíl.
Pokud je odměna postavená na revenue share, je nutné definovat, zda se počítá z obratu nebo z čistého zisku. Rozdíl je zásadní. Z obratu lze vyplácet snadněji a transparentněji, zatímco zisku je třeba nejprve odečíst náklady, což často vede ke sporům o účetní metodiku. U digitálních produktů je běžné nastavit podíl například z čistých příjmů po odečtení platebních poplatků, reklamy a cloudových nákladů, ale přesný výpočet musí být ve smlouvě explicitní.
Praktické je doplnit i kontrolní mechanismus:
- právo na nahlédnutí do účetních podkladů,
- termín vyúčtování, například jednou měsíčně nebo čtvrtletně,
- limit na zpětné reklamace, například 30 dní od doručení výkazu,
- auditní právo při podezření na nesprávné vykázání výnosů.
U projektů s vyšší hodnotou je vhodné použít i escrow nebo postupné financování podle milníků. Tím se minimalizuje riziko, že jedna strana uhradí velkou část nákladů, ale výsledek nebude odpovídat dohodě.
Bezpečnost, ukončení spolupráce a prevence sporů
Poslední část smlouvy by měla počítat i s tím, že spolupráce nemusí fungovat. Dobře napsaná exit strategie často rozhoduje o tom, zda projekt přežije změnu partnera, nebo skončí v právním chaosu. Je potřeba definovat, co se stane s rozpracovaným kódem, přístupy do Git repozitáře, cloudové účty, domény, analytikou a zákaznickými daty.
Ve smlouvě doporučuji mít tyto body:
- povinnost předat zdrojové kódy, dokumentaci a přístupová hesla při ukončení,
- zákaz zneužití know-how a důvěrných informací po dobu trvání i po skončení spolupráce,
- non-solicitation u klíčových lidí, pokud je to přiměřené a právně možné,
- pravidla pro vypořádání rozpracované práce a neuhrazených nákladů,
- určení rozhodného práva a soudu nebo arbitráže.
U digitálních produktů je rozumné doplnit i bezpečnostní standardy: správa přístupů přes 1Password nebo Bitwarden, dvoufaktorové ověření, oddělené účty pro produkci a staging, pravidelné zálohy a logování změn. Pokud se zpracovávají osobní údaje, je nutné sladit smlouvu také s GDPR a případně uzavřít zpracovatelskou smlouvu.
Nejlepší výsledky přináší, když právní text nevzniká izolovaně, ale společně s produktovým zadáním, technickou specifikací a finančním modelem. Jen tak bude smlouva skutečně použitelná v každodenním provozu, ne jen jako formální dokument v šuplíku.
