Co ovlivňuje cenu firemní aplikace a jak funguje strop

Cena firemní aplikace se odvíjí od několika faktorů: kolik uživatelských úkolů pokrývá a pro kolik typů uživatelů, jak připravený je návrh a API, na co se napojuje, co musí fungovat bez signálu, kolik testování vaše organizace potřebuje, a kolik práce dá vydání do dvou obchodů a udržení v nich. Počet obrazovek, číslo, kterým většina poptávek začíná, o žádném z nich moc neříká.

Proto žádné seriózní studio nenacení aplikaci z jednoho e-mailu. Dvě aplikace popsané každá jednou větou se mohou pracností lišit několikanásobně, jakmile jsou tyto faktory známé. Co z první výměny získat můžete, je seznam faktorů, které u vaší aplikace rozhodují, co obnáší každý z nich vyjasnit, a způsob práce, který odhad udrží pod kontrolou, jakmile práce začne.

Článek prochází jednotlivé faktory z pohledu toho, kdo aplikaci staví, co můžete připravit, abyste je zúžili, co skrývá pevná cena a jak v praxi funguje odhad se stropem. Cenové rozpětí záměrně neuvádí. Rozpětí bez faktorů, které za ním stojí, je odhad naslepo převlečený za odpověď, a naše ceny se sjednávají pro každý projekt zvlášť.

Proč počet obrazovek klame

Obrazovka je místo, kde se práce stane viditelnou, ne místo, kde probíhá. Seznam dnešních návštěv pro technika v terénu je malá práce, pokud API vrátí přesně tyto návštěvy, seřazené a stránkované. Je to podstatně větší práce, pokud API vrátí všechno a aplikace musí filtrovat, ukládat do mezipaměti a srovnávat. Obrazovka vypadá v obou případech stejně.

Odhadem hýbe počet různých věcí, které může uživatel udělat, počet typů uživatelů s různými právy, stav systémů, na které se aplikace napojuje, a všechno, co musí platit na okrajích: bez signálu, se starou verzí, která je ještě nainstalovaná, na čtyři roky starém telefonu, s dotazem od kontrolora v Applu. Tabulka níže ukazuje, jak zadání čteme my.

Co ovlivňuje cenu

Rozsah: úkoly a role

Počítejte, co lidé mohou udělat, ne co vidí. Technik, který otevře návštěvu, vyplní kontrolní seznam, zapíše dvě hodnoty, přidá fotografie, získá podpis a odešle, dělá jeden úkol o šesti krocích a každý krok má svůj chybový případ: nahrávání fotografie, které vyprší, podpis, který zákazník odmítne, návštěvu, kterou dispečink mezitím zrušil. Cena sedí v těchto případech. Druhá role, třeba vedoucí, který může odeslanou návštěvu znovu otevřít, není jedna obrazovka navíc; je to druhá sada práv, kterou musí API vynucovat a aplikace všude respektovat.

Nejlevnější rozhodnutí v každém projektu aplikace je to, které nechá úkol mimo první verzi. Jak to zapsat, ukazuje článek o podkladech pro nabídku.

Platformy: jeden kód, tři cesty k vydání

iOS a Android stavíme z jednoho kódu v React Native, webové aplikace v Next.js. Sdílený kód pokryje většinu firemní aplikace. Oddělené zůstává to, co sdílet nejde: sestavení, podepisování, schvalování v obchodě a testování na skutečných zařízeních pro každou platformu zvlášť, a nativní části, například platební nebo skenovací SDK, které přicházejí jako dvě knihovny se dvěma sadami zvláštností. Webová aplikace pro kancelář, běžná součást B2B produktů, je třetí plocha s vlastním hostingem a vlastními testy. Článek React Native pro firemní aplikace odděluje, co jeden kód odstraní a co ne.

Backend a integrace: kde sedí většina rozptylu

Ze všech faktorů vysvětluje stav API největší část rozdílu mezi dvěma odhady pro podobné aplikace. API, které už úkoly obsluhuje, s přihlášením a oprávněními vynucovanými na serveru a s testovacím prostředím s realistickými daty, dovolí začít prací na aplikaci. API, které vrátí všechno a spoléhá, že si to klient přebere, přesouvá do aplikace práci, která patří na server, a taková práce je křehká.

Stavíme na API, které máte. Když je třeba ho změnit, pracujeme s člověkem na vaší straně, který to může udělat. Vývoj backendu není standardní služba; u nového produktu se v rámci rozsahu dohodne, co potřebuje na straně serveru. Článek co musí umět vaše API, než začneme stavět aplikaci vyjmenovává, co ověřit.

Integrace jsou druhým zdrojem rozptylu. Každá externí služba, platební brána, dodavatel ověření identity, mapové SDK nebo elektronický podpis, přichází s vlastním účtem, smlouvou, testovacím režimem a často i vlastním schválením, než smí do provozu, a účet má být od začátku na jméno vaší firmy. Před Tolaronem jsem pět let pracoval jako senior mobilní vývojář a vedoucí týmu v britské platební instituci s licencí FCA a tempo každého vydání tam určovaly integrace, ne obrazovky.

Návrh: tři výchozí stavy

Připravenost návrhu má tři stavy a odhad je pro každý jiný. Hotový: postupy jsou navržené a schválené, možná už běží na vašem webu, a aplikace navazuje na existující design systém. Načrtnutý: hlavní postup je jasný, značka je známá, obrazovky nakreslené nejsou. Otevřený: o samotném produktu se teprve rozhoduje. Brand manuál napsaný pro tisk a web stále nechává komponenty aplikace, jejich stavy a animace k navržení, což je běžné a stojí za to to v rozsahu říct.

Discovery začíná jasnou představou o rozsahu projektu a zdarma vám formou MVP ukážeme, jak by aplikace zhruba mohla vypadat. Tento náhled není návrhářská práce; dává oběma stranám stejný obrázek dřív, než se sepíše rozsah.

Bezpečnost a soulad s pravidly: požadavky, ne nálepka

Bezpečnostní práce ve firemní aplikaci je konkrétní: šifrované úložiště v zařízení, pravidla pro relace a biometrické přihlášení, kontroly rootovaných nebo jailbreaknutých zařízení, pokud je vaše politika chce, auditní stopa, kdo co udělal, a výzvy a prohlášení k soukromí, které každá platforma vyžaduje. Každá položka je řádek v rozsahu s vlastníkem. Cenu nezvyšuje žádná z nich sama o sobě, ale požadavek, který přijde pozdě, až jsou postupy postavené.

Zda se na vaši aplikaci vztahuje GDPR, DORA nebo oborová pravidla a co vyžadují, je věc vaší organizace a jejích poradců. Stavíme podle požadavků, které určíte, každý držíme viditelný v rozsahu a nikdy za vás neprohlásíme vydání za vyhovující předpisům. Dva požadavky na úrovni platforem mají vlastní články: zákon o přístupnosti a dotaz na sledování v EU od iOS 27.2.

Testování na skutečných zařízeních

Testování je místo, kde odhady nejčastěji mlčí, protože se snadno předpokládá. Firemní aplikace potřebuje zařízení, která vaši lidé skutečně nosí, ne ta nejnovější, verze systému, které jsou ještě v provozu, data v podobě, jakou vaše systémy opravdu produkují, a nepříjemné cesty: přerušené nahrávání, vypršelou relaci, verzi o dvě vydání starší. Pak přejímací kolo na vaší straně, určenými lidmi, podle podmínek převzetí zapsaných v rozsahu. Každou z těchto položek vidíte v ceně předem, pokud ji rozsah pojmenuje.

Distribuce: dva obchody, někdy soukromý kanál

Veřejná aplikace se vydává dvakrát. Oba obchody registrují vaši firmu, ne dodavatele, a oba ji ověřují: Apple Developer Program stojí 99 USD ročně a po organizaci chce číslo D-U-N-S a osobu s oprávněním podepisovat; účet vývojáře v Google Play stojí jednorázově 25 USD a má vlastní ověření organizace. Poplatky jsou malé; skutečnou cenou je čas na zřízení, takže začněte brzy a účty držte na své jméno, jak vysvětluje článek komu patří vaše aplikace.

Každé vydání pak prochází schvalováním v každém obchodě, s texty a snímky obrazovek v každém jazyce, který podporujete, a pro každou třídu zařízení. Aplikace pro vaše vlastní zaměstnance do veřejných obchodů patřit nemusí; obě platformy nabízejí soukromou distribuci na zařízení organizace, která má vlastní zřízení i pravidla, a tato volba patří do rozsahu.

Po spuštění

Aplikace něco stojí i po vydání a je lepší znát tvar těchto nákladů hned. Operační systémy se mění každý rok, pravidla obchodů se posouvají, staré verze zůstávají na něčím telefonu a API je musí dál obsluhovat. Příkladem je požadavek Google Play na cílovou úroveň API: od 31. srpna 2026 musí nové aplikace a aktualizace cílit na Android 16. Monitoring, upozornění a to, kdo rozhoduje o opravě, se dohodnou pro váš projekt, nepředpokládají se. Provozní náklady podrobněji rozebírá článek aplikace, nebo mobilní web.

Co můžete připravit

Každá z těchto věcí zúží odhad dřív, než ho někdo napíše:

• Jeden úkol, který první verze musí dokončit, a role, které ho používají.
• Stav vašeho API: co dnes obsluhuje, kdo ho může změnit, zda existuje testovací prostředí s realistickými daty.
• Seznam externích služeb a kdo vlastní který účet.
• Co už existuje v návrhu: brand manuál, design systém webu, náčrty.
• Vaše požadavky na bezpečnost a posouzení, s osobou, která je schvaluje.
• Zařízení, která vaši uživatelé mají, a zda jde o spravované firemní telefony.
• Kdo práci přebírá a kdo vlastní účty v obchodech.

Neznámé zapište jako neznámé. „Nevíme jistě, zda to naše API umí“ je užitečnější než odhad naslepo, protože pojmenuje kontrolu, kterou mohou obě strany udělat, než se na odhad spolehnou.

Co skrývá pevná cena

Pevná cena působí bezpečně a u přesně specifikovaného rozsahu taková být může. U první verze, kde se faktory výše teprve objevují, musí pevná cena neznámé nějak zaplatit. V praxi to dělá třemi způsoby: rezervou na riziko, kterou platíte, ať riziko přijde, nebo ne; třením při změnách, kdy se každé zjištění změní ve vyjednávání o tom, co cena zahrnovala; a motivací vyřešit všechno, o čem specifikace mlčí, nejlevněji, ne správně.

Otázka pro studio nezní „jaká je vaše cena“, ale „co se stane, když se něco změní“. Odpověď řekne o výsledné ceně víc než samotné číslo.

Jak funguje odhad se stropem

Náš model je ten ze stránky vývoj mobilních aplikací a má čtyři části:

1. Rozsah písemně. Dodávky, výjimky, odpovědnosti, závislosti na vaší straně, podmínky převzetí.
2. Odhad a strop. Odhad je naše čtení rozsahu. Strop je schválený limit: nejvíc, co vám můžeme vyúčtovat bez nového rozhodnutí z vaší strany.
3. Skutečná práce účtovaná do stropu. Účtujeme skutečně odpracovaný čas. Pokud práce vyjde pod odhad, platíte méně, ne odhad.
4. Schválení před každým navýšením. Když se něco změní, rozhodujete vy, dřív než utratíme víc.

Tři slova, která se snadno slijí: odhad je to, co podle nás rozsah zabere; strop je schválený limit, se kterým jste souhlasili; závazek je to, co podle písemného rozsahu a podmínek převzetí dodáme. Strop omezuje, kolik zaplatíte, nezaručuje, že se každý řádek rozsahu pod něj vejde. Pokud se některý faktor ukáže větší, než rozsah předpokládal, třeba mezera v API, o které nikdo nevěděl, rozhodnete vy, co ustoupí, položka, strop, nebo termín vydání, dřív než se pohnou peníze.

Fiktivní příklad

Příklad je fiktivní a nepopisuje žádný klientský projekt. Používá firmu z našeho článku o podkladech pro nabídku.

Northline Services, fiktivní servisní firma, dohodne první verzi: dokončení návštěvy pro své techniky na iOS a Androidu, fungující offline, s fotografiemi a podpisem zákazníka, postavené na stávajícím dispečerském API. Písemný rozsah vyjmenuje úkol krok po kroku, co je mimo, testovací API, které Northline dodá, a Petru, vedoucí backendu, jako odpovědnou za změny API. Odhad je napsaný a strop stanovený nad ním.

Během práce se změní dvě věci.

Požadavek na změnu. Dispečink se zeptá, zda by technici mohli do fotografií kreslit a označit závadu. Odhadneme pracnost: zasahuje do postupu s fotografiemi a do pravidla pro synchronizaci offline a posunula by práci nad strop. Northline má tři možnosti: zvýšit strop, vyměnit funkci za něco z rozsahu, nebo ji odložit. Odloží ji do druhé verze. Strop se nemění a požadavek je zapsaný i s odhadem pracnosti, takže druhá verze začíná od známého čísla.

Zjištění. Ukáže se, že API nemá stránkování na koncovém bodu návštěv. Rozsah předpokládal, že má. Petra ho doplní na serveru, obchůzka, kterou by aplikace potřebovala, se z rozsahu škrtne a odhad klesne. Strop zůstává, kde byl; skutečná práce účtovaná pod ním je nižší.

Ani jeden případ nepotřeboval nové vyjednávání, protože rozsah už řekl, kdo rozhoduje a co se stane, když se odhad pohne.

Co následuje

Pokud srovnáváte studia, položte každému stejnou otázku: co ovlivňuje cenu naší aplikace a co se stane, když se něco změní. Pro naši odpověď na vaši aplikaci stačí krátké shrnutí: úkol, stav vašeho API, externí služby a vaše omezení, poslané přes kontaktní stránku. Stránka vývoj mobilních aplikací popisuje, jak projekt vymezujeme a co od vás potřebujeme.

Zdroje

• Apple Developer Program: Enrollment (členský poplatek 99 USD ročně; požadavky na organizaci včetně čísla D-U-N-S)
• Nápověda Google Play Console: How to register for a Google Play Developer account (jednorázový registrační poplatek 25 USD)
• Android Developers: Meet Google Play's target API level requirement (nové aplikace a aktualizace cílí na Android 16 od 31. srpna 2026)

Všechny zdroje byly ověřeny 10. října 2026.