Jak naplánovat vývoj SaaS aplikace: od prvního wireframu po spuštění

01Co je SaaS aplikace a proč se plánuje jinak než web

SaaS (software as a service, software jako služba) je aplikace, kterou zákazník neinstaluje. Používá ji v prohlížeči a platí za ni průběžně, obvykle měsíčně nebo ročně. Typickým příkladem jsou fakturační programy, CRM, rezervační systémy nebo docházka. Pro české firmy je to dnes běžný způsob, jak software kupovat. Podle Eurostatu platilo v roce 2025 za cloudové služby 54,9 % českých firem s deseti a více zaměstnanci, víc než je průměr EU (52,7 %).

Od běžného webu nebo interního nástroje se SaaS liší ve čtyřech věcech, které je potřeba naplánovat předem:

• Víc zákazníků v jedné aplikaci. Data každé firmy musí být oddělená tak, aby jeden zákazník nikdy neviděl data jiného.
• Týmy a role. Zákazníkem je firma s více uživateli. Majitel, účetní a běžný uživatel mají v aplikaci různá oprávnění.
• Předplatné. Tarify, zkušební období, změna tarifu, faktury, neúspěšné platby a DPH v různých zemích.
• Provoz, který nekončí. Nové verze se nasazují za běhu a zákazníci očekávají dostupnost, zálohy, podporu a bezpečnost po celou dobu, kdy platí.

Každou z těchto věcí jde doplnit i později, jen za výrazně víc peněz. Proto má plán SaaS víc kroků než plán webu.

02Krok 1: zadání, které se vejde na jednu stránku

Než kdokoli nakreslí první obrazovku, sepište zadání na jednu stránku. Donutí vás rozhodnout o tom podstatném a všichni, od vás přes grafika po programátory, pak vycházejí ze stejného zadání.

• Pro koho: konkrétní typ zákazníka a role uživatelů. Kdo platí a kdo aplikaci denně používá.
• Problém a dnešní řešení: jak to lidé řeší teď: v Excelu, e-mailem, na papíře nebo v jiném programu.
• Hlavní cesta uživatele: jedna věta od registrace k výsledku, kvůli kterému zákazník zaplatí.
• Cenový model: za firmu, za uživatele, nebo podle objemu. Měsíčně, nebo ročně. Ovlivní databázi i fakturaci.
• Metrika úspěchu: podle čeho po třech měsících poznáte, že první verze funguje. Třeba počet platících firem nebo podíl uživatelů, kteří se vracejí.
• Rozpočet a termín: včetně rezervy a včetně provozu po spuštění.
• Omezení: jazyky, země, napojení na účetnictví, banku nebo CRM, zákonné požadavky.

Pokud má aplikace nahradit tabulky, na kterých dnes firma stojí, sepište i to, co v nich lidé dělají ručně. Právě to bývá jádro první verze. Víc o tom, kdy se tabulka stává brzdou, píšeme v článku Kdy už firmě nestačí Excel.

03Krok 2: uživatelské toky a wireframy

Uživatelský tok (user flow) je jednoduchý diagram cesty uživatele k cíli: odkud přijde, na jaké obrazovky narazí a kde se rozhoduje. Nakreslete nejdřív hlavní cestu a pak ty, na které se zapomíná: registraci a pozvání kolegy do týmu, zapomenuté heslo, změnu tarifu, neúspěšnou platbu, zrušení předplatného a export dat.

Z toků vzniknou wireframy, tedy černobílé náčrty obrazovek. Ukazují, co na obrazovce je a v jakém pořadí. Vzhled přijde na řadu až později. Záměrně jsou bez barev a fotek, aby se debata točila kolem obsahu a ovládání. Podle Kary Pernice z Nielsen Norman Group je prototyp hypotéza, tedy návrh řešení, který teprve ověřujete. Čím jednodušší prototyp, tím méně času zabere příprava a tím víc ho zbude na samotný návrh. Tři pojmy, které se často pletou:

Nástroj není podstatný. Stačí papír, tabule nebo Figma, kde licence Professional pro jednoho návrháře stojí 16 USD měsíčně při ročním placení. Wireframy dělejte pro počítač i mobil. SaaS se většinou ovládá na počítači, ale schválení, upozornění nebo rychlý přehled lidé řeší v telefonu. Jestli k aplikaci potřebujete i mobilní verzi, pomůže rozhodnout článek Nativní, nebo multiplatformní aplikace.

04Krok 3: klikací prototyp a test s pěti lidmi

Ze schválených wireframů udělejte klikací prototyp a dejte ho do ruky lidem z cílové skupiny. Nic nevysvětlujte. Zadejte úkol, třeba „vystavte fakturu a pošlete ji klientovi“, a sledujte, kde váhají. Jakob Nielsen z Nielsen Norman Group zjistil, že pět testujících najde zhruba 85 % problémů s ovládáním. Víc se vyplatí několik malých kol než jeden velký test.

Testujte proto v kolech: pět lidí, opravy, dalších pět. Oprava v prototypu zabere hodiny. Stejnou chybu nalezenou až v hotové aplikaci musí tým opravit v návrhu, v kódu i v testech. Jak najít lidi z cílové skupiny a jak s nimi vést rozhovor, popisujeme v článku Od nápadu k MVP.

Prototyp je také nejlepší podklad pro cenovou nabídku. Dodavatel vidí každou obrazovku, a jeho odhad tak vychází ze skutečného rozsahu práce. Pokud vám někdo nabízí pevnou cenu bez prototypu nebo aspoň wireframů, ptejte se, z čeho ji spočítal.

05Krok 4: rozsah první verze

Největší past při plánování je chtít všechno hned. Firma Pendo analyzovala anonymní data o používání softwaru svých zákazníků a v reportu z roku 2019 došla k tomu, že v průměrném softwarovém produktu platí: 80 % funkcí se používá zřídka nebo nikdy. Na pouhých 12 % funkcí připadá 80 % každodenního používání.

Pomůže jednoduché třídění MoSCoW. Každou funkci zařaďte do jedné ze čtyř skupin:

• Musí (Must): bez toho zákazník neprojde hlavní cestou a nezaplatí.
• Měla by (Should): důležité, ale první zákazníci se bez toho chvíli obejdou.
• Mohla by (Could): příjemné navíc, přidá se podle dat z používání.
• Teď ne (Won't): vědomě odložené, aby se k tomu debata nevracela každý týden.

Do první verze patří jen skupina „musí“. Test je jednoduchý: když funkci škrtnete, projde zákazník pořád hlavní cestou a zaplatí? Pokud ano, funkce počká.

Z toho vznikne backlog, seznam úkolů seřazený podle priority. Každou položku popište z pohledu uživatele a přidejte podmínku, kdy je hotová. Například: „Jako majitel firmy chci pozvat kolegu e-mailem, aby mohl vystavovat faktury. Hotovo, když pozvánka dorazí, odkaz platí sedm dní a pozvaný nevidí nastavení plateb.“ Takhle popsaný úkol se dá odhadnout, naprogramovat i otestovat.

06Krok 5: rozhodnutí, která se později špatně mění

Většinu věcí v aplikaci jde změnit kdykoli. Několik rozhodnutí ale prorůstá celým kódem i databází a jejich změna po spuštění znamená týdny práce a přesun dat zákazníků. O nich rozhodněte před prvním řádkem kódu:

Platby a DPH

Pro platby kartou a předplatné je často používanou volbou Stripe. Podle českého ceníku stojí platba standardní kartou z EHP 1,5 % + 6,50 Kč a správa předplatného přes Stripe Billing dalších 0,7 % z objemu. U předplatného za 500 Kč tak zaplatíte za jednu platbu asi 17,50 Kč.

Pokud prodáváte spotřebitelům v jiných zemích EU, hlídejte DPH. Jakmile vaše přeshraniční prodeje spotřebitelům v EU překročí 10 000 eur bez DPH za rok (limit platí za všechny státy EU dohromady), odvádíte DPH podle sazby státu zákazníka. Abyste se nemuseli registrovat v každém státě zvlášť, můžete využít zvláštní režim jednoho správního místa, zkráceně OSS, a daň přiznávat čtvrtletně. U firemních zákazníků z jiných zemí EU s platným DIČ se obvykle uplatní přenesení daňové povinnosti. Nastavení proberte s daňovým poradcem. Aplikace ale musí od začátku umět uložit zemi a DIČ zákazníka a spočítat správnou sazbu.

Osobní údaje a přístupnost

Jako provozovatel SaaS pro firmy zpracováváte osobní údaje jejich zákazníků a zaměstnanců. Podle čl. 28 GDPR musí být takové zpracování upraveno smlouvou mezi vámi a zákazníkem, tedy smlouvou o zpracování osobních údajů. Při úniku osobních údajů musí správce, tedy váš zákazník, podle čl. 33 ohlásit únik dozorovému úřadu, v Česku ÚOOÚ, bez zbytečného odkladu a pokud možno do 72 hodin od chvíle, kdy se o něm dozvěděl. Vy jako zpracovatel musíte podle čl. 33 odst. 2 informovat zákazníka o úniku bez zbytečného odkladu. Aplikace by také měla umět osobní údaje najít, vyexportovat i smazat, protože o to vás zákazník jako správce může požádat. Co musí vedení firmy zařídit kvůli GDPR a NIS2 ještě před spuštěním, shrnuje článek Únik dat stojí průměrně 107 milionů Kč.

Od 28. června 2025 je účinný zákon č. 424/2023 Sb. o požadavcích na přístupnost některých výrobků a služeb (platí od 29. 12. 2023). Vztahuje se mimo jiné na služby elektronického obchodování poskytované spotřebitelům. Na služby poskytované mikropodniky se nevztahuje. Čistě firemní SaaS pod něj většinou nespadá. I tak se vyplatí stavět podle standardu WCAG 2.2, protože dodatečné úpravy rozhraní jsou dražší než přístupný návrh od začátku.

07Krok 6: vývoj v krátkých cyklech

Vývoj rozdělte na krátké cykly s viditelným výsledkem. Podle Scrum Guide trvá sprint nejvýš měsíc, v praxi se osvědčuje týden nebo dva. Basecamp ve své metodě Shape Up pracuje v šestitýdenních cyklech, po kterých následují dva týdny bez plánované práce (cool-down), určené na rozmyšlení dalšího cyklu. Důležitější než metodika je rytmus. Na konci každého cyklu musí být něco, co si proklikáte na testovací verzi.

1. Plán: pár položek z backlogu s jasnou podmínkou, kdy jsou hotové.
2. Testovací verze online: každá změna se sama nasadí na testovací adresu, kde si ji vyzkoušíte.
3. Ukázka: krátká schůzka, kde tým předvede hotovou práci na skutečných datech.
4. Rozhodnutí: co dál, co škrtnout, co odložit.

Malá a častá nasazení jsou i otázkou stability. Podle zprávy DORA 2024 nejlepší týmy nasazují podle potřeby i několikrát denně, selže jim jen 5 % nasazení a po neúspěšném nasazení obnoví provoz do hodiny. Nejslabší týmy nasazují jednou za měsíc až půl roku a selže jim 40 % nasazení.

Domluvte si i společnou definici hotové práce. Hotovo neznamená „funguje u programátora“. Kód zkontroloval druhý vývojář, má automatické testy, běží na testovací verzi, funguje v mobilu i na počítači, texty jsou ve všech jazycích a vy jste změnu odsouhlasili. A počítejte s rezervou v čase i rozpočtu. Změny přijdou vždy, protože teprve fungující aplikace ukáže věci, které v prototypu vidět nebyly.

08Krok 7: beta a příprava spuštění

Před ostrým spuštěním pusťte aplikaci pár zákazníkům v uzavřené betě. Ideálně těm, kteří testovali prototyp nebo si produkt předplatili dopředu. Několik týdnů ostrého provozu odhalí chyby, na které žádný test nepřijde, protože je způsobí až skutečná data, různé prohlížeče a spěch.

Než otevřete registraci všem, projděte si šest otázek. Každé „ne“ je úkol, který je lepší dodělat před spuštěním než po prvním problému.

Pokud zákazníkům slibujete dostupnost, spočítejte si, co číslo znamená. Dostupnost 99,9 % dovoluje výpadek asi 43 minut za měsíc, za rok necelých 8 hodin 46 minut. Stejnou hranici měsíční dostupnosti slibuje třeba Google Workspace. Na začátku je poctivější slíbit méně a dodržet to.

Bezpečnost projděte bod po bodu podle našeho checklistu bezpečnosti webové aplikace před spuštěním. Nejčastější chyby, přes které z aplikací unikají data, rozebírá článek Chyby v kódu, přes které unikají data. Server, HTTPS a cloudové služby zabezpečíte podle návodu Jak zabezpečit server, HTTPS a cloud před spuštěním.

09Spuštění a prvních 30 dní

Spuštěním začíná měření. V prvních týdnech sledujte hlavně pět čísel:

• Aktivace: kolik registrovaných firem udělá hlavní akci, třeba vystaví první fakturu nebo pozve kolegu.
• Retence: kolik firem aplikaci používá i po týdnu a po měsíci.
• Odchody (churn): kolik platících zákazníků za měsíc zruší předplatné a proč.
• MRR: měsíční opakovaný příjem z předplatného.
• Chyby a rychlost: kolik chyb zachytí monitoring a jak rychle se aplikace načítá.

Kapacitu na první měsíc plánujte hlavně na opravy a drobná vylepšení podle zpětné vazby. Velké nové funkce počkají, až data ukážou, co zákazníci opravdu potřebují. Tady se zúročí práce z kroku 4: položky „měla by“ a „mohla by“ už máte sepsané a teď víte, v jakém pořadí je stavět.

10Harmonogram a rozpočet

Typická první verze SaaS aplikace s předplatným, týmy a rolemi vypadá v čase zhruba takto:

Kolik to stojí? V naší kalkulačce vychází SaaS aplikace orientačně na 400 až 800 tisíc korun bez DPH a 12 až 20 týdnů od zadání po spuštění. To je typická první verze. Náročnější projekty s mnoha napojeními na jiné systémy, složitými oprávněními, více jazyky, přísnou regulací nebo mobilní aplikací se podle náročnosti a všech okolností dostanou i do milionů korun. Přehled cen všech služeb najdete v ceníku.

K ceně vývoje připočtěte provoz. U malé aplikace začínají typické služby na desítkách dolarů měsíčně. Ceny podle ceníků výrobců k září 2026:

Jak u nás vypadá spolupráce od první schůzky po předání, popisujeme na stránce Jak to probíhá.

11Nejčastější chyby při plánování SaaS

• Programovat dřív, než je jasný tok. Každá změna pak stojí kód, testy i nervy.
• Příliš velká první verze. Pokud platí, že 80 % funkcí se používá zřídka nebo nikdy, každá funkce navíc jen odkládá spuštění a první data.
• Zapomenuté okrajové cesty. Zrušení předplatného, neúspěšná platba, odchod člověka z týmu nebo export dat se ukážou až u prvního zákazníka.
• Role a oddělení dat až později. Nejdražší přestavba, jakou SaaS může mít.
• Žádný rozpočet na provoz. Hosting, monitoring, podpora a další vývoj stojí peníze i po spuštění.
• Spuštění bez měření. Bez aktivace a retence víte jen to, že aplikace běží.

12Časté otázky

13Závěr: dobrý plán je levnější než dobrý kód

Úspěšná SaaS aplikace řeší jeden problém lépe než dosavadní řešení a od začátku počítá s předplatným, týmy a provozem. Nejlevnější místo, kde to zajistit, je papír: zadání, toky, wireframy a prototyp.

Pokud máte nápad ověřený a chcete ho proměnit v aplikaci, podívejte se, jak stavíme webové aplikace, nebo si v kalkulačce spočítejte orientační cenu a termín.

14Zdroje

• Eurostat: Cloud computing services by size class of enterprise (isoc_cicce_use), data za rok 2025, aktualizace 27. 2. 2026
• Jakob Nielsen: Why You Only Need to Test with 5 Users, Nielsen Norman Group, 18. 3. 2000
• Kara Pernice: UX Prototypes, Low Fidelity vs. High Fidelity, Nielsen Norman Group, 18. 12. 2016
• Pendo: The 2019 Feature Adoption Report
• Stripe: ceník plateb a ceník Billing, stav 27. 9. 2026
• Finanční správa: One Stop Shop (OSS), Evropská komise: One Stop Shop a Your Europe: DPH při přeshraničním prodeji
• GDPR čl. 28 a čl. 33
• Zákon č. 424/2023 Sb. o požadavcích na přístupnost a WCAG 2.2
• Scrum Guide 2020 a Basecamp: Shape Up, kapitola Cool-down
• DORA: Accelerate State of DevOps Report 2024
• Google Workspace: Service Level Agreement
• Ceníky Figma, Vercel, Neon a Sentry, stav 27. 9. 2026