Převzetí vývoje softwaru: pět signálů a co od prvních 30 dnů očekávat.

Většina firem přijde na výměnu dodavatele pozdě — typicky šest až dvanáct měsíců poté, co projekt začal tiše stagnovat. Rozhodnutí se odkládá, protože „přece už tolik dáno do investice". V naší praxi se opakuje pět konkrétních signálů, které stojí za to brát vážně okamžitě, jak se objeví.

Prudký pokles tempa dodávek. Tým, který v prvním půlroce dodal funkční MVP, se najednou pohybuje kolem dvou až tří ticketů měsíčně. Nejde o složitost — jde o motivaci, fluktuaci nebo o to, že váš projekt přestal být u dodavatele prioritou.

Dokumentace existuje jen v hlavách lidí. Když se zeptáte, jak je nasazená produkce, a odpověď zní „to ví Honza", máte problém bez ohledu na to, co kód umí. Ve chvíli, kdy Honza odejde, jde s ním celý projekt.

Nasazení bez incidentu je výjimka, ne pravidlo. Pokud se hot-fix na produkci stal rutinou, znamená to, že testovací procesy klesly pod udržitelnou hranici. Otázka není „jestli", ale „kdy" se to projeví na zákazníkovi.

Faktury běží, ale business metrika se nehýbá. Po roce vývoje by firma měla říct, jaké KPI se zlepšilo. Pokud odpovědí jsou jen technické featury bez vazby na měřitelný výsledek, je čas na nezávislý audit.

Odchod klíčového člověka na straně dodavatele. Malé agentury mají často projekt postavený na jednom seniorovi. Když odejde, projekt přechází na juniora, který ho vidí poprvé.

Prvních 30 dnů od podpisu rozhoduje, jestli projekt zachráníte, nebo skončíte u rewritu od nuly. V Etyce máme šablonu, kterou jsme vyladili na čtyřech převzetích. Není to univerzální zázrak, ale rámec, který v 80 % případů sedí.

Týden 1 — audit kódu, infrastruktury a přístupů. Dostáváme repository, produkční přístupy, DNS, certifikáty, monitoring, faktury za SaaS. Souběžně analyzujeme architekturu a kvalitu kódu — vyhneme se tím nepříjemnému zjištění o tři týdny později. U projektu **NemovitostiČesko** jsme v prvním týdnu identifikovali kritické zranitelnosti a chybějící DDoS ochranu, což zásadně přeskupilo prioritizaci dalších týdnů.

Týden 2 — stabilizace ostrého provozu. Než se začne cokoliv nového vyvíjet, musí být produkce v měřitelném stavu. Nasazený monitoring, alerting, automatizované zálohy a CI/CD pipeline, která neselhává. U převzetí mobilní aplikace **Ordinačka** jsme nejdřív museli opravit build, který týden nebyl schopen projít přes App Store review.

Týden 3 — předávací dokumentace a runbook. Sepíšeme všechno, co dosud bylo v hlavě jednoho člověka — postup nasazení, rollback, kontakty na třetí strany, licence, vlastnické vztahy k doménám. Bez toho nelze projekt řídit, ani když máte sebelepší tým.

Týden 4 — první vlastní změna do produkce. Nejde o velkou funkci. Je to důkaz, že nový tým umí projekt měnit bez incidentu. Typicky drobná oprava, hlavička e-mailu, nasazení feature flag systému. Pokud čtvrtý týden propadne, je něco špatně v týdnu 1–3 a je čas si to přiznat.

Převzetí není jeden formát. V naší praxi vidíme tři dominantní scénáře, které se liší rozsahem práce, riziky i tempem. Nedělejte tu chybu, že na všechny tři přijdete se stejnou nabídkou — pak buď podstřelíte, nebo zbytečně přeplatíte.

Záchrana opuštěného projektu. Předchozí dodavatel nereaguje, kód běží na produkci, ale bez podpory. Typicky 30denní deadline, protože něco hoří — buď byznysově, nebo bezpečnostně. **NemovitostiČesko** byl přesně tento případ. Projekt jsme dostali v kritickém stavu, dotáhli ho do produkce za 30 dní s 98,5 % SLA a chybovostí sníženou o 90 %. Cena tohoto formátu je vyšší per MD, protože pracujete pod tlakem a často přes víkendy.

Převzetí stagnujícího projektu. Předchozí dodavatel komunikuje, ale rok dodává jen parciální funkcionalitu. Klient se rozhodne pro výměnu, ale není v akutní krizi. Realistický horizont na stabilizaci a dotažení do plné funkčnosti je čtyři až sedm měsíců. **Autoškola ABC v Brně** byla tento scénář — předchozí dodavatel rok dodával jen části systému, my jsme za zhruba půl roku dodali kompletní ERP a CRM s 40% zrychlením rozvrhování a 60% poklesem příchozích telefonátů díky self-service portálu.

Dokončení rozpracovaného MVP. Startupový kontext — funkční prototyp existuje, je potřeba ho dotáhnout do publikovatelné podoby. U mobilní aplikace **Ordinačka** jsme dokončili MVP po neúspěšném předchozím dodavateli a dostali aplikaci do App Store i Google Play, včetně in-app subscription a push notifikací. U tohoto formátu se nevyplatí přepisovat — vyplatí se vyčistit a stabilizovat.

Cena za převzetí v nabídce je obvykle 60 až 70 % skutečných nákladů prvních šesti měsíců. Zbytek tvoří položky, které dodavatelé buď nevidí, nebo je úmyslně vynechávají, aby cena na vstupu vypadala přijatelně.

Licenční dluh a third-party služby. Když přebíráte projekt, přebíráte i jeho účty — neaktualizovaná Mongo Atlas, vypršelé SSL, drahá Cloudinary subscription, kterou nikdo nezrušil, Stripe v test módu. U jednoho z našich převzetí jsme v prvních dvou měsících uspořili kolem 18 tisíc Kč měsíčně jen tím, že jsme vyčistili nepoužívané SaaS účty.

Refactoring kvůli compliance. Pokud máte ISO 9001, ISO 27001 nebo plánujete due diligence, převzatý kód je obvykle nevyhovující — chybí audit trail, role-based access, šifrování citlivých polí. Compliance refactoring zabere typicky 15 až 25 % celkové ceny převzetí.

Datový cleanup. Stará databáze má historicky narostlé struktury, duplicity, sirotky bez vazeb. Vyčištění je nudná, ale nutná práce — bez ní vám analytika lže.

Hand-off SLA a hyper-care. Ne každý dodavatel si do ceny započítá tři měsíce zvýšené pohotovosti po nasazení. Bez toho se incidenty řeší ad-hoc, draho a v noci.

Než podepíšete smlouvu o převzetí, projděte těchto sedm otázek. Pokud dodavatel některou nedokáže odpovědět konkrétně, ptejte se dál nebo si vyžádejte druhou nabídku.

1. Kolik převzetí už mají za sebou a v jakých vertikálách. Převzetí PHP portálu, Next.js SaaS aplikace a native mobilní aplikace jsou tři odlišné disciplíny. Reference v jiném oboru je jen orientační.

2. Kdo konkrétně bude na vaší straně tech lead — jméno, ne role. Tech lead dělá v převzetí kolem 70 % rozdílu mezi úspěchem a problémem. Nepodepisujte smlouvu, kde tech lead není pojmenovaný.

3. Jaký mají proces pro audit kódu v prvním týdnu. Pokud odpověď zní „začneme rovnou vyvíjet", je to varování. Bez auditu nový tým nezná, čeho se má vyvarovat.

4. Jak řeší předávací dokumentaci od předchozího dodavatele. Existuje šance, že žádná není. Co pak — kolik dní reverse engineeringu si naúčtují a jak to bude transparentně reportovat?

5. Jaké compliance certifikace mají (ISO 9001, ISO 27001, GDPR DPA). Bez toho vám neprojde audit u většího klienta ani due diligence pro investora.

6. Jaký je SLA model po hand-offu. Reakce do 4 hodin v pracovní době je standard pro běžné SMB aplikace, do 30 minut pro mission-critical systémy. Co se stane, když SLA poruší — penalizace, kredit, nebo nic?

7. Mají referenci, kterou si můžete telefonicky ověřit. Ne logo na webu, ale konkrétního CTO nebo IT manažera, který si s vámi 20 minut popovídá o tom, jak konkrétně proběhlo jejich převzetí.

Pokud zvažujete převzetí konkrétního projektu, ozvěte se nám. Úvodní audit v rozsahu do 5 MD děláme bez závazku a do týdne dostanete rámcovou nabídku s realistickým odhadem rozsahu — i s položkami, které jiní dodavatelé do první kalkulace nepíšou.