Kolik reálně stojí software na míru

Dostanete tři nabídky. Jedna je 300 tisíc, druhá 600 tisíc, třetí 1,1 milionu. Všechny na totéž. Jak máte vědět, která je správná?

Krátká odpověď: nevíte, protože nekupujete totéž. A tady začíná problém, který trápí každého, kdo si kdy nechal udělat software na míru.

Hodinovka nic neřekne

Nejčastější srovnávací ukazatel je hodinová sazba. Kodér z outsourcingové firmy za 800 Kč/h vypadá levněji než senior architekt za 2 500 Kč/h. Ale to srovnání má smysl jen tehdy, když víte, co každý z nich za hodinu vyprodukuje.

Senior architekt v první verzi navrhne datový model, který zvládne růst aplikace tři roky bez refactoru. Kodér ho navrhne tak, jak se mu to zdá logické — a za rok budete platit refactor, který bude stát víc než úspora na sazbě.

Hodinovka je cena práce. Hodnota práce je jiná věc. Obojí musíte vědět.

Blended rate: průměr, který nic neříká

Agentury a větší týmy často prezentují jednu sazbu za celý tým — tzv. blended rate. Je to průměr přes všechny role. Může být 1 200 Kč/h.

Jenže 1 200 Kč/h jako průměr juniorního vývojáře na 800 Kč/h a seniora na 2 000 Kč/h říká málo o tom, kdo na vašem projektu skutečně rozhoduje. Pokud architekt strávil designem systému tři dny a zbytek odevzdal juniorům bez dohledu, zaplatili jste průměrnou cenu za podprůměrný výsledek.

Správná otázka není „jaká je vaše hodinovka". Je to: kdo reviewuje architekturu, kdo dělá klíčová rozhodnutí, kolik % kapacity toho člověka dostanu?

Kdy SaaS stačí a kdy ne

Existuje software, který je zbytečné stavět. Pokud potřebujete fakturovat, posílat emaily, sbírat formuláře nebo zpracovávat platby — pro každou z těchto věcí existuje hotový produkt za stovky korun měsíčně. Dává smysl ho použít.

Bod zlomu nastane, když potřebujete, aby to fungovalo uvnitř vašeho systému — ne vedle něj.

Příklad: SaaS řešení pro e-fakturaci v rámci KSeF zvládne vystavit fakturu. Ale pokud ta faktura musí vzniknout automaticky z vaší ERP databáze, projít schvalovacím workflow, uložit UPO (potvrzení od státu) zpět do záznamu objednávky a spustit účetní zápis — balíkový produkt tam narazí. Buď to neumí, nebo to umí s tolikem kompromisů, že integrační náklady převýší úsporu.

Otázka před každým rozhodnutím: potřebuji to jako izolovaný nástroj, nebo jako součást procesu? Pokud jako součást procesu, spočítejte integraci, ne jenom licenci.

Proč fixní cena selhává

Fixní cena zní bezpečně. Víte, kolik zaplatíte. Riziko nese dodavatel.

V teorii. V praxi se to láme na jednom místě: specifikace se píše po domluvení ceny, ne před.

Dodavatel nacení projekt na základě vašeho slovního popisu. Pak napíše specifikaci. A tam se poprvé ukáže, co jste každý myslel jinak — jaká data přijdou ze starého systému, kdo schvaluje, co se stane při chybě, co musí systém zvládnout v lednu, když přijde deset tisíc dokladů najednou.

Každý bod, kde se specifikace liší od původního popisu, je spor. Buď ho dodavatel absorpbuje a šetří na kvalitě, nebo vám přijde změnové řízení. Obojí je špatně.

Řešení je obrátit pořadí. Nejdřív specifikace, pak cena. Říká se tomu spec-first přístup a je to jediný způsob, jak fixní cena dává smysl. Specifikace je pracný dokument — ale je to ten správný dokument, za který platíte, protože z něj pak víte přesně co dostanete.

Tři cenové modely

T&M (čas a materiál): Platíte za odpracované hodiny. Transparentní, flexibilní na změny, ale bez stropu. Vhodné, když přesně nevíte, co chcete — nebo když víte, že se to bude měnit.

Fixní scope: Platíte za výsledek, ne za hodiny. Funguje jen tehdy, když máte hotovou specifikaci před začátkem. Jakákoliv změna v průběhu je nové kolo jednání.

FLEX: Méně běžný model, ale v některých situacích dává smysl. Platíte po etapách nebo jako podíl z dosažených výsledků (například z úspory, která prokazatelně vznikla). Klient vlastní kód od prvního dne, žádný vendor lock-in. Dodavatel má zájem na výsledku, ne na maximalizaci hodin. Funguje tam, kde jde výsledek měřit.

Každý model má smysl za jiných podmínek. Pokud vám firma nabídne jen jeden — bez vysvětlení proč — ptejte se.

Co levnější varianta ve skutečnosti stojí

Nejlevnější nabídka skoro nikdy není nejlevnější projekt.

Sekvence je předvídatelná: rychlá implementace, žádná architektura, žádné testy. Rok funguje. Pak přidáte funkci a rozbije se něco jiného. Přijde nový vývojář, orientuje se tři týdny, pak přidá svůj kód vedle starého. Po třech letech máte aplikaci, kde nikdo nechce šahat do ničeho, protože nikdo neví, co to rozbije.

Rework přijde. Otázka je jen jestli za rok nebo za tři. A rework celé aplikace stojí víc než udělat to dobře napoprvé.

Tenhle výpočet málokdo dělá předem, protože rework je v budoucnosti a úspora je teď.

Na co se ptát, než podepíšete

Pár otázek, které vám ušetří nervy:

• Kdo navrhuje architekturu a kolik % jeho kapacity dostanu?
• Máte zkušenost s tímto typem integrace, nebo to budete řešit poprvé?
• Jak vypadá specifikace, podle které nacenujete? Mohu ji vidět před podpisem?
• Co se stane, když zjistíme nový požadavek v průběhu? Jak ho zpracujete?
• Kdo vlastní kód a dokumentaci po skončení projektu?

Dobrý dodavatel na tyto otázky odpoví bez zaváhání. Špatný změní téma.

---

FAQ

Proč se odhady tak liší?

Protože každý odhaduje jiný projekt. Bez podrobné specifikace každý odhaduje svou představu toho, co slyšel. Jeden počítá s jednoduchým REST API, druhý s full-textovým vyhledáváním a auditním logem. Rozsah se liší, takže se liší i cena. Jedinou cestou ke srovnatelným nabídkám je dodat všem uchazečům stejný vstup — tedy specifikaci.

Kdy SaaS a kdy custom?

SaaS dává smysl, dokud software existuje vedle vašich procesů — jako nástroj, který otevřete, použijete a zavřete. Jakmile potřebujete, aby byl hluboce provázaný s vaším ERP, datovými toky, schvalovacím procesem nebo reportingem, SaaS naráží. Integrační náklady a kompromisy v designu pak snadno převýší cenu custom řešení. Spočítejte celkové náklady vlastnictví za tři roky, ne jenom licenci.

Co je FLEX model?

FLEX je cenový model, kde platíte postupně — po etapách nebo jako podíl z měřitelného výsledku (úspora času, snížení chybovosti, automatizovaný objem). Klient od začátku vlastní kód, čímž odpadá vendor lock-in. Dodavatel má přímou vazbu na výsledek, ne na počet hodin. Funguje tam, kde je výsledek měřitelný a obě strany si věří natolik, aby se na metriku dohodly předem.