Co dostanete při předání softwaru, aby ho převzal jiný tým?

Tohle je oprávněná obava. Jsme malé studio a nemáme klientské reference, kterými bychom mohli doložit úspěšné převzetí zakázky jiným dodavatelem. Můžeme ukázat naše vlastní produkty, používané technologie a zveřejněné podmínky předání. Slib, že osobní výpadek nikdy nezpůsobí komplikace, by poctivý nebyl.

„Bus factor“ označuje závislost projektu na konkrétních lidech. Pro majitele firmy je podstatné, zda při jejich nedostupnosti zůstane přístupný kód, provozní účty a znalosti potřebné k pokračování. Pokud zásadní postup existuje pouze v něčí hlavě, samotné vlastnictví souborů problém nevyřeší.

Na stránce o našem postupu uvádíme běžný stack Next.js, TypeScript a PostgreSQL, automatické testy a CI, tedy automatické kontroly změn. Jiný tým se tak nemusí učit proprietární vývojový nástroj Iteru. Stále ale potřebuje pochopit konkrétní aplikaci, její pravidla a návaznosti.

Pracujeme AI-native: vývoj akcelerujeme nástroji Claude Code a Codex, kvalitu jistíme automatizovanými testy, nezávislým code review a specialisty na vyžádání.

Způsob vývoje sám o sobě není důkaz snadného převzetí. Ten získáte až praktickou zkouškou předávaných podkladů. Rozsah spolupráce a předání popisujeme také zde:

Na webu uvádíme, že klient po zaplacení vlastní 100 % zdrojového kódu a dokumentace. Podle našich obchodních podmínek tím právně rozumíme licenci popsanou níže. Pro možnost změnit dodavatele záleží právě na jejím rozsahu.

Zaplacením celé ceny díla nebo předávané etapy získáváte k autorským dílům vytvořeným pro vás výhradní licenci, neomezenou časově, územně, množstevně ani způsobem užití. Zahrnuje úpravy, spojování s jinými díly, poskytování podlicencí i postoupení licence dalším osobám. S postoupením podle podmínek předem souhlasíme a odměna za licenci je zahrnuta v ceně.

Podmínky zároveň rozlišují výstupy zakázky od komponent třetích stran. Open-source knihovny a další cizí komponenty používáte podle jejich původních licencí uvedených v předávacím seznamu. Obecné nástroje, postupy a know-how vytvořené Iterem nezávisle na zakázce zůstávají Iteru; klient k nim získává nevýhradní, časově neomezenou licenci v rozsahu potřebném k užívání díla.

Podmínky pamatují také na čistě automaticky vytvořené části výstupu: klient k nim získává veškerá existující práva, která může Iterus poskytnout. Při posuzování konkrétní smlouvy nebo nejasných licenčních požadavků zapojte právníka. Přesné znění najdete zde:

Podle našich obchodních podmínek předáváme dílo nebo jeho etapu se zdrojovým kódem, dokumentací a seznamem komponent třetích stran včetně open-source licencí. Pro praktické převzetí doporučujeme předem sjednat konkrétní obsah těchto podkladů. Následující body berte jako kontrolní seznam pro zadání předání; závazný rozsah určují obchodní podmínky a ujednání vaší zakázky.

Zdrojový kód v repozitáři. Repozitář uchovává soubory i historii změn. Při předání má být jasné, která verze běží v produkci, odkud se nasazuje a kdo může spravovat přístup. Nastupující tým potřebuje rozlišit hotové změny od rozpracovaných větví.

Dokumentace aplikace a dat. Užitečný popis vysvětluje účel aplikace, hlavní části, uživatelské role a napojení na jiné systémy. Má obsahovat návod ke spuštění a popis změn databáze. Patří sem také známá omezení a rozhodnutí, jejichž důvod nelze snadno vyčíst z kódu.

Komponenty a licence. Seznam má novému týmu umožnit zjistit, na čem aplikace stojí a jaké podmínky se k použitým součástem vztahují. Vedle knihoven je praktické evidovat placené služby a jejich účel. U každé služby potřebujete vědět, kdo spravuje účet a kdo hradí provoz.

Testy a automatické kontroly. Nestačí mít složku označenou „testy“. Předávací podklady mají vysvětlovat jejich spuštění, potřebná testovací data a význam výsledku. Zelený výsledek kontroly neříká, že aplikace nemá chyby; říká, že prošly konkrétní ověřované scénáře.

Nasazení a provozní přístupy. Doporučený rozsah zahrnuje sestavení aplikace, nastavení prostředí, nasazení, zálohy a obnovu. Přístupové údaje patří do bezpečného předávacího postupu, nikoli do běžné dokumentace v repozitáři. Podstatné je ověřit skutečnou správu hostingu, databáze, domény i navázaných služeb.

Tento rámec se hodí už při zadávání nové aplikace. Pomůže určit, co má být při převzetí prokazatelně připravené.

Doporučujeme převzetí vyzkoušet v odděleném prostředí. Nastupující tým dostane podklady a přístupy určené pro tuto zkoušku a postupuje podle dokumentace. Každá nutná ústní nápověda ukazuje místo, které je vhodné doplnit do předání.

Krátký checklist pro společnou kontrolu:

• Získá firma kód, dokumentaci a přístupy k provozním účtům i bez součinnosti zakladatele?
• Má firma správu repozitáře a může přidat nového dodavatele?
• Je dohledatelná verze odpovídající aplikaci v provozu?
• Dokáže nastupující tým podle návodu aplikaci spustit a nasadit?
• Umí spustit testy a rozumí případným selháním?
• Má přehled o databázi, zálohách, externích službách a jejich správcích?
• Jsou známé vady, omezení a nedokončené práce písemně uvedené?
• Odpovídá seznam komponent skutečně předávané aplikaci?

Běžně používané technologie usnadňují hledání týmu s odpovídající zkušeností. Samy však nezaručují srozumitelnou dokumentaci ani úplné přístupy. Proto má větší vypovídací hodnotu úspěšné nasazení podle návodu než seznam technologií v nabídce.

Naším vlastním produktem v provozu je Innea, která používá Next.js, TypeScript a Supabase s PostgreSQL; mezi její testovací nástroje patří Vitest a Playwright. Je to konkrétní příklad našeho stacku, nikoli klientská reference nebo doklad předání cizímu týmu.

Podle obchodních podmínek má klient do 10 pracovních dnů od předání dílo vyzkoušet a buď potvrdit převzetí, nebo písemně popsat vady bránící užívání. Pokud v této lhůtě neudělá ani jedno, považuje se dílo nebo etapa za převzaté. Na tento následek při každém předání výslovně upozorňujeme.

Drobné vady, které užívání nebrání, podle podmínek nebrání převzetí a opravíme je v rámci záruky. Prakticky proto doporučujeme rezervovat si na kontrolu čas předem a případné nedostatky popsat reprodukovatelně: co jste udělali, co mělo nastat a co se skutečně stalo.

Podmínky stanovují záruku 3 měsíce od převzetí a bezplatnou opravu vad oznámených v této době v přiměřené lhůtě. Záruka se nevztahuje například na vady způsobené zásahem klienta či třetí strany, změnou prostředí nebo služeb třetích stran ani na požadavky nad sjednaný rozsah.

Před zásahy nastupujícího týmu je proto užitečné zaznamenat výchozí stav a existující vady. Usnadní to rozlišení původního problému od následné změny. Smluvní pravidla převzetí a záruky jsou zde:

1. Musíme při změně dodavatele aplikaci přepsat?

   Samotná změna dodavatele není důvodem k přepisu. Nový tým by měl nejdřív posoudit stav kódu, dokumentace, testů a provozu. Teprve z konkrétních zjištění lze rozhodnout, které části potřebují úpravu.

2. Je předání u Iteru placené zvlášť?

   Podle zveřejněného popisu našeho postupu je předání součástí ceny každého cenového pásma, nikoli příplatek. Konkrétní rozsah podkladů a ověřovací zkoušky doporučujeme uvést v zadání.

3. Můžeme si aplikaci dál upravovat sami?

   Podle našich obchodních podmínek licence po zaplacení celé ceny díla nebo etapy zahrnuje právo úprav. U komponent třetích stran platí jejich původní licence. U následných zásahů je zároveň potřeba rozlišit původní vady od vad způsobených těmito změnami.

4. Kdo projekt převezme, když zakladatel nebude dostupný?

   Můžete si vybrat jiný tým se zkušeností s použitými technologiemi. U konkrétní zakázky je vhodné předem ověřit, že přístupy a podklady získáte i bez osobní součinnosti zakladatele. Náhradního provozovatele ani garantovanou dobu převzetí neslibujeme.