Cena vychází z toho, co má aplikace zvládnout
Kolik stojí vývoj mobilní aplikace? Pro konkrétní cenu je potřeba vymezit funkce, napojení na data a rozsah dodávky. Počet obrazovek nestačí: za jedním tlačítkem může být jednoduché uložení formuláře i složitá rezervace s platbou, kontrolou kapacity a storno podmínkami.
Rozpočet si rozdělte na vytvoření aplikace a její následný provoz. Návrh obrazovek, programování a testování tvoří první část. Hosting, externí služby, řešení chyb a aktualizace patří do druhé. Nabídky lze rozumně porovnat až ve chvíli, kdy zahrnují stejné položky.
Z čeho se skládá rozpočet
| Část dodávky | Co má být vyjasněné |
|---|---|
| Zadání a návrh | Uživatelské cesty, obrazovky, pravidla a hranice první verze. |
| Mobilní aplikace | Podporované platformy, přihlášení, funkce a chování při chybě. |
| Backend a administrace | Databáze, oprávnění, správa obsahu a dostupné API. |
| Integrace | Platby, firemní systémy, notifikace a případná migrace dat. |
| Ověření a vydání | Testovací zařízení, příprava podkladů a vydání do obchodů. |
| Provoz a péče | Hosting, služby třetích stran, aktualizace a rozsah podpory. |
U každé položky má být zřejmé, co dodáte vy, co připraví vývojář a co závisí na další straně. Chybějící dokumentace externího systému může být pro odhad větší nejistotou než samotné obrazovky aplikace.
Dvě podobné aplikace, rozdílný rozsah
Příklad A: přehled zakázek pro zaměstnance
Firma už má backend a zdokumentované API. Aplikace zobrazí zakázky přihlášeného pracovníka, detail úkolu a umožní změnit stav. Pracuje online a obsahuje jednu uživatelskou roli. Hlavní práce se soustředí na rozhraní, oprávnění, napojení a testování.
Příklad B: platforma pro zákazníky a dodavatele
Vedle mobilní aplikace vzniká backend a administrace. Zákazníci vytvářejí zadání, dodavatelé posílají nabídky, systém řeší různé role a upozornění. Přibývají pravidla přístupu, návaznosti mezi stavy a více scénářů k ověření.
Jde o modelová zadání, nikoli cenové nabídky. Rozdíl ukazuje, proč není užitečné oceňovat jen počet obrazovek. Podobné souvislosti popisuje případová studie Zhotoveno.cz.
MVP: nejdřív ověřit zájem, potom rozšiřovat
MVP (Minimum Viable Product) je první použitelná verze produktu s funkcemi potřebnými k vyřešení jednoho hlavního problému. Umožní skutečným uživatelům aplikaci vyzkoušet a vám zjistit, zda o ni mají zájem.
Měsíce vývoje bez kontaktu s uživateli mohou skončit aplikací, kterou trh nechce. Menší první verze přinese zpětnou vazbu dřív a omezí investici do neověřeného nápadu. Podle výsledků můžete pokračovat, změnit směr nebo vývoj zastavit.
Jak při vývoji MVP postupuji
- Vyberu hlavní funkci. S vámi upřesním, pro koho produkt vzniká a jaký problém má vyřešit. Vedlejší funkce odložím.
- Vytvořím použitelný základ. Uživatel musí zvládnout hlavní úkol od začátku do konce. Menší rozsah nesmí znamenat nefunkční nebo nespolehlivou aplikaci.
- Pomohu ověřit přijetí trhu. Navrhnu, co sledovat: dokončení hlavního úkolu, návraty uživatelů a u placené služby ochotu zaplatit. Doplním rozhovory a připomínky uživatelů.
- Navrhnu další rozvoj podle výsledků. Přednost dostanou úpravy, které řeší skutečné překážky v používání. Na funkčním základu pak postupně stavím další části produktu.
Například první verze rezervační aplikace může nabídnout výběr termínu, rezervaci a potvrzení. Věrnostní program nebo pokročilé statistiky mohou počkat, až se ověří, že zákazníci službu používají. MVP úspěch nezaručí, ale pomůže včas poznat, do čeho má smysl dál investovat.
S jakými náklady počítat po vydání
Vedle hostingu a databáze mohou vznikat poplatky za e-maily, SMS, mapy, platební služby nebo AI. Některé závisejí na počtu uživatelů a požadavků. Ceníky a podmínky konkrétních dodavatelů proto patří k návrhu řešení.
Počítejte také s aktualizacemi, sledováním chyb, zálohami a obnovou provozu. Rozsah podpory, reakční dobu a způsob zadávání dalšího vývoje je vhodné dohodnout před spuštěním.
Pokud plánujete integraci AI, zahrňte do rozpočtu i ověřování kvality výstupů, limity spotřeby a případnou lidskou kontrolu.
Co poslat pro konkrétní nabídku
- Kdo bude aplikaci používat a jaký problém řeší.
- Jeden hlavní scénář od otevření aplikace po dokončení úkolu.
- Funkce nezbytné pro první verzi a funkce na později.
- Informace o existujícím webu, backendu, datech a externích službách.
- Požadované platformy, termín a rozpočtový rámec.
- Představu o podpoře a rozvoji po spuštění.
Technickou specifikaci mít nemusíte. Stačí popis fungování a několik příkladů. Z nich připravím podklady pro vývoj mobilní aplikace na míru.