Kolik stojí vývoj aplikace: jak srovnat nabídky

Modelová situace: firma chce aplikaci na míru, zadání pošle třem dodavatelům a nejdražší ze tří nabídek je násobkem té nejlevnější. První podezření bývá jasné: někdo předražuje.

Rozdíl ale může být v tom, co dodavatel do nabídky započítal, co vynechal a jaké riziko nechal na vás.

Zda se vlastní systém vyplatí, rozebíráme v článku Dobrý interní systém se může zaplatit dřív než nový zaměstnanec. Tady začínáme o krok později: nabídky leží na stole a otázka zní, kolik stojí vývoj aplikace, když si ji každý dodavatel představuje jinak.

Násobný rozdíl nemusí znamenat předražování

Bente Anda, Dag Sjøberg a Audris Mockus popsali ve studii z roku 2009 výběrové řízení, ve kterém Simula Research Laboratory hledala dodavatele webového systému. Z 81 oslovených firem v Norsku podalo nabídku s fixní cenou 35, všechny na tutéž 11stránkovou specifikaci. Částky bez DPH se pohybovaly od 2 630 do 69 940 eur, což je přibližně 26,6násobný rozdíl. Poučný je poměr, ne dnes už historické částky.

Firmy přitom zadání považovaly za dobře specifikované. Nabídky se přesto lišily i rozsahem analýzy a návrhu: některé je neobsahovaly vůbec, jiné zahrnovaly i obrazovky, architekturu a datové modely. Souvislost ceny s plánovaným postupem autoři nenašli a z nabídek se podle nich dalo jen omezeně vyčíst, jak firma pracuje a jakou kvalitu chce dodat. Samotná částka tedy neprozradí, co za ni dostanete.

V předběžné fázi téhož řízení dalo 17 z těchto firem nezávazný odhad jen na základě jednostránkového popisu potřeb. Magne Jørgensen a Gunnar J. Carelius uvádějí, že nejvyšší odhad byl přibližně desetkrát vyšší než nejnižší, mimo jiné kvůli rozdílům v navrhovaných řešeních a v produktivitě. Autoři upozorňují, že při vágní specifikaci cena nabídky projekt nejen odráží, ale také definuje.

Z čeho se cena skládá

Pokud zadání mlčí, udělá tato rozhodnutí za vás dodavatel:

Rozsah funkcí. Co aplikace bude a nebude dělat. Věta „uživatel si vygeneruje report“ může znamenat export do tabulky i analytický modul.
Integrace. Propojení například s účetnictvím. Jejich náročnost závisí na rozhraních, která dodavatel nemusí znát.
Design a UX. UX, tedy uživatelský prožitek, ovlivňuje, zda lidé aplikaci přijmou, jak píšeme v článku Nejdražší systém je ten, který vaši lidé nepoužívají. Hotová šablona je levnější než návrh ověřený s uživateli.
Datový model. Struktura dat a vztahů mezi nimi. Stojí na něm všechno ostatní, proto se jeho chyby opravují obtížně.
Bezpečnost a oprávnění. Jedna role pro všechny je levná, přístupy podle pozice je třeba navrhnout i otestovat.
Testování. Automatizované testy po každé změně ověří, že původní funkce stále fungují. Bez nich testují vaši lidé.
Projektové řízení. Koordinace a řízení změn. Ověřte, zda je v ceně, nebo ho bude zajišťovat někdo z vaší firmy.

Rozdíly se skrývají i v nefunkčních požadavcích, které nepopisují, co systém dělá, ale jak dobře to dělá: rychlost, spolehlivost nebo udržovatelnost, tedy jak snadno se dá měnit. V norské studii byly popsány méně podrobně než funkční požadavky a autoři doporučují specifikovat je už v zadání, zejména udržovatelnost. Pomoci může model kvality z normy ISO/IEC 25010:2023, který mohou při specifikaci používat i objednatelé.

Co v nabídce nemusí být

Tyto položky si ověřte u každého dodavatele. Pokud je zadání nezmiňovalo, jeden je mohl započítat a druhý ne.

Administrace. Správa uživatelů, číselníků a obsahu. Bez ní dělá každou drobnou změnu vývojář na fakturu.
Migrace dat. Přenos a vyčištění dat ze starého systému nebo z tabulek.
Vícejazyčnost. Pokud s ní kód od začátku nepočítá, její doplnění může zasáhnout velkou část aplikace.
Přístupnost. Použitelnost i pro lidi se zdravotním postižením. Řešit ji dodatečně znamená předělávat hotové obrazovky.
Podpora po spuštění. Opravy, bezpečnostní aktualizace a pomoc uživatelům. Pokud chybí, první problém v provozu znamená novou objednávku.

Náklady za roky používání rozebíráme v článku Sedm SaaS nástrojů nebo jeden systém? Při čtení nabídky si z něj stačí vzít jedno: kód bez testů a dokumentace je levnější dodat, ale dražší měnit, protože vývojář musí při každé úpravě nejdřív zjistit, co změna rozbije.

Kdo nese riziko: fixní cena, time and materials, hybrid

Fixní cena znamená, že riziko překročení nákladů nese dodavatel, a proto si ho započítá do ceny: čím vágnější zadání, tím větší rezerva nebo užší výklad rozsahu. Americký předpis pro federální zakázky, Federal Acquisition Regulation, uvádí, že smlouva s pevnou cenou klade na dodavatele maximální riziko a o typu smlouvy se má vyjednávat spolu s cenou. U nás tento předpis neplatí, jeho logiku ale považujeme za přenosnou.

Time and materials znamená, že platíte odpracované hodiny podle dohodnutých sazeb a riziko nejistoty nesete vy. Tentýž předpis ho připouští, jen když rozsah nebo trvání prací nelze předem přesně odhadnout. Protože tento model nemotivuje dodavatele ke kontrole nákladů, předpis vyžaduje dohled objednatele. Vyžaduje také cenový strop, který dodavatel překračuje na vlastní riziko.

Hybrid s fixním prvním milníkem stanoví pevnou cenu pro první etapu s jasným výstupem, například pro analýzu nebo prototyp, a o zbytku se rozhoduje až ve chvíli, kdy je rozsah popsaný. Dodavatel nese riziko malé etapy a vy o většině rozpočtu rozhodujete s lepšími informacemi. První etapa ale stojí peníze i čas a její výstup musí umět použít i jiný dodavatel, jinak si závislost koupíte o etapu dřív.

Za nepřesné zadání se platí během vývoje

Změnový požadavek (change request) je formální žádost o změnu dohodnutého rozsahu s vlastní cenou a dopadem na termín. Při nepřesném zadání se z výjimky stává pravidlo, protože chybějící části se ukážou až během vývoje.

Jørgensen a Carelius píší, že častou příčinou překročení nákladů dodavatele jsou změny požadavků, které nelze vyfakturovat klientovi. Kdo zakázku vyhrál nízkou cenou, má proto podle nás silný motiv účtovat každou odchylku jako změnu. Pokud smlouva předem nestanoví sazbu, způsob odhadu a schvalování změn, vyjednáváte o jejich ceně ve chvíli, kdy už dodavatele snadno nevyměníte.

Nepřesné zadání ale neplatíte jen fakturami. Rámec Cost of Friction, který na blogu používáme, počítá náklady tření jako čas × frekvence × počet lidí × náklad. Modelový výpočet s hypotetickými vstupy: 30 nejasných bodů zadání, z nichž každý zabere dvě hodiny schůzky tří vašich lidí, znamená 2 × 30 × 3 = 180 hodin interní práce. Nikdo vám ji nevyfakturuje, a přesto ji zaplatíte. Dosaďte vlastní čísla a hodinový náklad.

Práva ke kódu a možnost změnit dodavatele

Vendor lock-in je stav, kdy dodavatele nemůžete snadno vyměnit, protože systému rozumí jen on. Evropská komise v roce 2016 uvedla, že zkušenost s lock-inem v oblasti ICT přiznalo 42 % sledovaných organizací.

Podle § 91 odst. 4 slovenského autorského zákona č. 185/2015 Z. z. ve znění účinném od 1. září 2026 se na počítačový program vytvořený zcela nebo zčásti na objednávku vztahují ustanovení o zaměstnaneckém díle a objednatel se považuje za zaměstnavatele. Není-li dohodnuto jinak, vykonává tedy majetková práva objednatel, zejména právo dílo užít, může jejich výkon postoupit třetí osobě a platí, že autor souhlasil i se změnou díla (§ 90 odst. 4 až 6). To je slovenská právní úprava; jiné státy to mohou upravovat jinak. Bez ohledu na zemi by proto smlouva měla výslovně určit, komu kód patří.

Dílem na objednávku zákon rozumí dílo vytvořené na základě smlouvy o dílo a rozhoduje i to, na čem se strany dohodly. Zákon navíc řeší práva, ne předání: bez zdrojového kódu ve vašem repozitáři, přístupů a dokumentace vám právo dílo měnit příliš nepomůže.

Smlouva má upravit i hotové části, které dodavatel přinese, například jeho platformu nebo placené komponenty, protože ty nevznikly na vaši objednávku. Nejde o právní poradenství, smlouvu nechte posoudit advokátem.

Jak nabídky srovnat

Pošlete všem dodavatelům stejné otázky a odpovědi si zapište vedle sebe:

Co je v rozsahu a co z něj výslovně vylučujete?
Z jakých předpokladů jste vycházeli u integrací, dat a rolí?
Jak řešíte výkon, bezpečnost a udržovatelnost a co testujete?
Jak naceňujete a schvalujete změny rozsahu?
Co zahrnuje podpora po spuštění a kolik stojí první rok provozu?
Jaká práva ke kódu získáme, kde bude uložený a jak proběhne předání jinému dodavateli?

Autoři norské studie doporučují, aby nabídky uváděly pracovní postupy a ambice v oblasti kvality výslovně, ne jen skrytě ve fixní ceně. Za varovné signály považujeme:

Fixní cena bez otázek. Vágní zadání naceněné pevnou částkou bez upřesňujících otázek může stát na úzkém výkladu rozsahu nebo na rezervě, o které nevíte.
Chybějící testování. Chyby pak najdou až vaši uživatelé.
Nejasná práva a přístupy. Není jasné, kde bude kód uložený, nebo jsou přístupy vázané na trvání spolupráce.

Kdy je levnější nabídka správnou volbou

Čtyři firmy z norské studie nakonec systém nezávisle na sobě vyvinuly. Nejlevnější z nich, za 8 750 eur, měla skluz 93 % oproti dohodnutému termínu a slabou spolehlivost i udržovatelnost. Nejdražší, za 56 000 eur, měla skluz 5 % a dobrou použitelnost i udržovatelnost. Podle ceny byla 6,4krát dražší, po započtení práce objednatele už jen 3,4krát. Výsledky nekopírovaly pořadí cen a levnější systém mohl být podle autorů nejlepší volbou pro objednatele, který toleruje zpoždění, má dostatečnou odbornost a nižší nároky na některé aspekty kvality.

Může jít například o interní nástroj s krátkou životností nebo o ověření nápadu.

V datech Magneho Jørgensena z 785 325 převážně velmi malých zakázek na globálním outsourcingovém tržišti riziko selhání nejvíce snižovala předchozí spolupráce klienta s dodavatelem, a to na 17 % úrovně projektů bez ní. Klienti, kteří vybrali nabídku s cenou alespoň na úrovni průměru, měli za jinak stejných podmínek riziko na 85 % úrovně klientů, kteří kladli větší důraz na nízkou cenu. Na větší projekty to lze podle autora zobecnit jen opatrně. Dodavatele podle něj nejlépe prověří realistická zkouška, například skutečný projekt, a tou může být malá placená první etapa.

Úvodní fáze mění odhad v plán

Steve McConnell popisuje kužel nejistoty, model zpřesňování odhadu v průběhu projektu. Ve fázi úvodního konceptu mohou být i odhady zkušených odhadců čtyřnásobně nepřesné oběma směry, tedy s 16násobným rozptylem, a přesněji to podle něj nejde. Kužel nezúží další týden práce na odhadu, zúží ho jen rozhodnutí o tom, co produkt bude a nebude dělat, o požadavcích a o rozhraní.

Tato rozhodnutí přináší analýza nebo prototyp. Dodavatelé pak naceňují alespoň stejný rozsah, i když podobné ceny to nezaručí, jak ukázala norská studie.

Firmy, které v uvedeném řízení nejdřív odhadovaly z jednostránkového popisu, později nabídly na podrobnou specifikaci v průměru vyšší ceny než ostatní. Jørgensen a Carelius proto doporučují nežádat orientační ceny na základě neúplných informací, pokud mohou finální nabídky vycházet z úplnějších.

Placená analýza přitom není povinná. U malé a jasně ohraničené aplikace může stačit upřesnit zadání vlastními silami. Analýza může ukázat i to, že vývoj nepotřebujete, protože problém vyřeší zjednodušení procesu nebo hotový nástroj. Na otázku, kolik stojí vývoj aplikace, proto neexistuje poctivá odpověď dřív, než je jasné, jaký problém má aplikace řešit.

Co si z toho vzít

Násobný rozdíl mezi nabídkami nemusí znamenat předražování. Může jít o jiný rozsah, řešení nebo rezervu na riziko.
Všem dodavatelům pošlete stejné otázky a srovnávejte rozsah, vyloučené položky a předpoklady, ne jen konečné částky.
Pokud lze zadání upřesnit, nežádejte orientační ceny na základě vágního popisu. Při nejasném rozsahu začněte úvodní fází za fixní cenu, jejíž výstup může použít i jiný dodavatel.
Před podpisem si ve smlouvě upravte práva ke kódu, přístupy, dokumentaci i hotové komponenty a nechte ji posoudit advokátem.
Levnější nabídka může být správnou volbou, pokud snesete zpoždění, máte nižší nároky na kvalitu a dodávku dokážete odborně uhlídat.