Jak postavit SaaS platformu od nuly — technický průvodce pro zakladatele

"Chci vybudovat SaaS." Tahle věta padne na každém třetím callu, který vedeme. Zakladatel má nápad, má peníze, má urgenci. Nemá ale ponětí, jaké technické rozhodnutí ho čeká v prvním týdnu a proč špatná volba v březnu znamená přepisování celé aplikace v říjnu.

Tento průvodce je pro vás, pokud máte nápad na softwarový produkt a chcete pochopit, co stavba SaaS platformy reálně obnáší. Žádná teorie z učebnic. Konkrétní rozhodnutí, konkrétní náklady, konkrétní chyby.

Co SaaS technicky znamená — a proč vás to musí zajímat

SaaS je software, který běží na vašem serveru a zákazníci k němu přistupují přes prohlížeč. Neinstalují si nic. Platí měsíčně nebo ročně. Vy se staráte o provoz, aktualizace, bezpečnost.

Zní to jednoduše. Není.

První technické rozhodnutí, které musíte udělat, je architektura tenantů. Multi-tenant znamená, že všichni zákazníci sdílí jednu databázi a jednu instanci aplikace. Single-tenant znamená, že každý zákazník má vlastní izolovanou kopii.

Multi-tenant je levnější na provoz. Jedna databáze, jeden server, jeden deployment. Když máte sto zákazníků, pořád provozujete jednu aplikaci. Náklady rostou pomalu.

Single-tenant je dražší, ale jednodušší na izolaci dat. Každý zákazník má vlastní prostředí. Když jeden z nich rozbije něco ve svém účtu, ostatní to nepoznají. Některé enterprise firmy to vyžadují smluvně.

Pro většinu startupů je odpověď jasná: multi-tenant. Pokud nestavíte pro banky nebo zdravotnictví, kde regulace vyžaduje fyzickou izolaci dat, jděte touhle cestou. Ušetříte statisíce na infrastruktuře v prvním roce.

Výběr technologického stacku

Tady zakladatelé tráví příliš času. Debatují, jestli Go nebo Rust, jestli microservices nebo monolith, jestli Kubernetes nebo bare metal. Mezitím nemají ani jednoho platícího zákazníka.

Řekněme si to rovně. Pro MVP, které má ověřit, jestli za váš produkt někdo zaplatí, potřebujete:

Frontend postavený na Reactu, ideálně v Next.js. Je to nejrozšířenější framework na trhu, má obrovskou komunitu, najdete na něj vývojáře a máte hotovou infrastrukturu pro SEO, routing a server-side rendering. Pokud váš SaaS potřebuje veřejný marketing web a zároveň aplikační dashboard, Next.js zvládne oboje v jednom projektu.

Backend buď v Node.js, nebo v Pythonu. Node.js má výhodu, že celý tým píše jeden jazyk — TypeScript na frontendu i backendu. Python má výhodu v ekosystému pro data a AI. Pokud váš produkt pracuje s daty, strojovým učením nebo automatizací, Python je logická volba. Jinak Node.js.

Databáze PostgreSQL. Bez diskuse. Je zdarma, je spolehlivá, zvládne relační data i JSON dokumenty, má skvělou podporu pro fulltextové vyhledávání a škáluje se daleko za hranice, které kdy dosáhnete v prvním roce. MySQL je taky validní volba, ale PostgreSQL je v roce 2026 standard.

Serverless versus tradiční server. Vercel, Netlify nebo AWS Lambda vám umožní nasadit aplikaci bez správy serverů. Platíte za reálné použití. Pro MVP do tisíce uživatelů je to ideální — nulové náklady na infrastrukturu, dokud nemáte traffic. Tradiční server na Hetzner nebo DigitalOcean dává smysl, jakmile měsíční účet za serverless přeroste pět tisíc korun. To se typicky stane kolem tisíce aktivních uživatelů.

A co ORM? Prisma je v ekosystému Node.js/TypeScript nejpoužívanější. Definujete databázový model v jednom souboru, Prisma vám vygeneruje typově bezpečné klientské API. Migrace databáze řeší za vás. Pro Python je ekvivalent SQLAlchemy nebo Django ORM. Obě volby jsou validní a ušetří vám stovky hodin oproti psaní raw SQL dotazů.

Nejdůležitější pravidlo: neoptimalizujte předčasně. Monolith, jeden server, jeden deployment. Microservices jsou pro firmy s dvaceti vývojáři a milionovými rozpočty na infrastrukturu. Vy máte dva lidi a potřebujete dostat produkt na trh. Každá hodina strávená nad architektonickými diagramy je hodina, kterou jste nestrávili mluvením se zákazníky.

Autentizace a billing — dva problémy, které sežerou třetinu rozpočtu

Tohle nikdo neříká nahlas, ale autentizace a platby jsou nejtěžší části každého SaaS produktu. Ne proto, že by byly technicky složité. Ale proto, že musí fungovat bezchybně od prvního dne a mají desítky edge cases, na které narazíte až v produkci.

Autentizace. Přihlášení, registrace, reset hesla, dvoufaktorové ověření, pozvánky do týmu, role a oprávnění. Stavět tohle od nuly je minimálně sto hodin práce. A pak údržba, bezpečnostní aktualizace, compliance.

Clerk vám tohle vyřeší za hodiny. Stojí pár dolarů měsíčně do tisíce uživatelů, má hotové komponenty pro React, zvládá multi-tenant organizace, SSO, magic links. Auth0 je enterprise alternativa — robustnější, dražší, složitější na integraci. Vlastní řešení doporučujeme jen tehdy, když máte specifické regulatorní požadavky nebo tým, který se autentizací živí.

Billing a předplatné. Stripe je standard. Funguje v Česku, podporuje české koruny, eurové a dolarové platby, má hotové řešení pro předplatné, fakturaci, zkušební období, promo kódy. Integrace zabere dva až pět dní čistého vývoje, ale otestování všech scénářů — upgrade, downgrade, zrušení, neúspěšná platba, refund — to je další týden.

Paddle je alternativa, která vám navíc vyřeší DPH v celé EU. Funguje jako Merchant of Record, takže fakturuje za vás. Pro SaaS, který prodává do více zemí, to ušetří hodiny účetnictví měsíčně. V Česku funguje bez problémů.

Počítejte s tím, že autentizace a billing spolknou dvacet až třicet procent celkového vývojového času. Každý zakladatel to podceňuje. Každý.

Rozsah MVP — co postavit a co vynechat

Nejčastější chyba, kterou vidíme: zakladatel přijde s padesátistránkovou specifikací. Tři typy uživatelů, deset modulů, integrace se třemi externími systémy, mobilní aplikace, analytický dashboard.

To není MVP. To je produkt na dva roky.

MVP je jedna funkce, za kterou jsou lidé ochotní zaplatit. Jedna. Ne tři, ne pět. Jedna.

Basecamp začal jako jednoduchý to-do list se sdílením. Slack byl interní chat pro herní studio. Dropbox byl složka, která se synchronizovala mezi dvěma počítači. Linear byl issue tracker, který byl rychlý. To je celé.

Pravidlo zní: pokud nedokážete jednou větou říct, co váš produkt dělá a proč za to někdo zaplatí, nemáte MVP — máte seznam přání.

Takhle vypadá správný rozsah MVP:

Registrace a přihlášení. Jeden hlavní workflow, kvůli kterému zákazník přišel. Nastavení účtu. Stránka s cenami a platba. Jednoduchý onboarding. Hotovo.

Vynechte: mobilní aplikaci, pokročilé reporty, API pro třetí strany, integrace s CRM, notifikace přes SMS, vlastní doménu pro zákazníky, vícejazyčnost. Tohle všechno přidáte, až budete mít padesát platících zákazníků a budete vědět, co reálně chtějí.

Jeden příklad z praxe. Český SaaS pro správu nemovitostí. Zakladatel chtěl v MVP: správu nájemníků, automatické generování smluv, napojení na katastr, platební bránu, tenant portál a mobilní aplikaci. Celkový odhad: čtrnáct měsíců, dva miliony korun. Nakonec jsme ho přesvědčili, aby začal s jednou věcí: přehled nemovitostí a sledování plateb nájemného v jedné tabulce s notifikacemi. Tři měsíce vývoje. Prvních dvacet zákazníků do šesti týdnů od launche. Teprve pak se přidávaly další funkce — ty, o které zákazníci skutečně žádali. Ne ty, které si zakladatel vymyslel u tabule.

Infrastruktura a provozní náklady

Kde váš SaaS poběží a kolik to bude stát. Konkrétní čísla v korunách, protože "to záleží" nikomu nepomůže.

Vercel je ideální pro začátek. Free tier zvládne vývojové prostředí a nízký provoz. Pro tier stojí okolo pěti set korun měsíčně a pokryje běžné MVP s desítkami až stovkami uživatelů. Výhoda: nulová správa serverů, automatické deploymenty z Gitu, edge network po celém světě.

Hetzner je v Česku populární volba pro produkční provoz. Dedikovaný server za tři sta korun měsíčně, cloud instance od sto padesáti korun. Datacéntrum ve Finsku a Německu, latence do Prahy pod dvacet milisekund. Když přerostete serverless, Hetzner vám sníží měsíční náklady na třetinu oproti AWS.

AWS je standard pro škálování. Ale taky nejdražší volba. Malá aplikace na AWS snadno stojí pět až deset tisíc měsíčně. Dává smysl, až když potřebujete specifické služby — SQS pro fronty, Lambda pro background joby, RDS pro managed databázi.

Reálné měsíční náklady na infrastrukturu podle počtu uživatelů:

Sto uživatelů: Vercel Pro + managed PostgreSQL na Supabase nebo Neon. Měsíčně asi tisíc dvě stě korun. Minimální údržba.

Tisíc uživatelů: Hetzner cloud server + vlastní PostgreSQL + Redis pro cache + S3-kompatibilní úložiště pro soubory. Měsíčně tři až pět tisíc korun. Potřebujete monitoring a zálohy.

Deset tisíc uživatelů: Dva až tři servery na Hetzner nebo přechod na AWS/GCP. Load balancer, replikovaná databáze, CDN. Měsíčně patnáct až třicet tisíc korun. Potřebujete DevOps člověka alespoň na částečný úvazek.

Nepočítejte sem další náklady: doména, SSL certifikáty (většinou zdarma přes Let's Encrypt), emailový provider pro transakční emaily (Resend, Postmark — pár set korun měsíčně), error tracking (Sentry — zdarma do určitého objemu), analytika.

Kolik to celé stojí v korunách

Tady přestává romantika a začíná realita. Konkrétní rozpočty pro konkrétní fáze.

MVP — dvě stě až pět set tisíc korun. To je dva až čtyři měsíce práce jednoho až dvou vývojářů. Dostanete funkční aplikaci s jedním hlavním workflow, autentizací, billingem a základním UI. Žádné animace, žádný design systém, žádné pokročilé funkce. Ale funguje to, lidé se můžou registrovat a zaplatit.

Kam peníze jdou: šedesát procent backend a business logika, dvacet procent frontend, patnáct procent autentizace a billing, pět procent infrastruktura a deployment.

Production-ready — pět set tisíc až milion a půl korun. Čtyři až osm měsíců. MVP plus: propracovaný UI/UX, onboarding flow, emailové notifikace, základní analytika, admin panel, automatizované testy, CI/CD pipeline, dokumentace API. Tohle je verze, kterou můžete ukázat investorovi a za kterou se nestydíte.

Scale-ready — milion a půl až pět milionů korun. Osm až osmnáct měsíců. Production-ready plus: API pro třetí strany, pokročilé reporty, integrace s externími systémy, multijazyčnost, enterprise funkce (SSO, audit log, custom branding), performance optimalizace, bezpečnostní audit. Tohle je produkt, který zvládne tisíce zákazníků a má infrastrukturu pro růst.

Důležité: tyto částky platí pro Česko. V západní Evropě nebo USA počítejte dvoj- až trojnásobek. To je mimochodem jeden z důvodů, proč má smysl stavět SaaS s českým týmem — náklady jsou výrazně nižší, kvalita srovnatelná.

Ještě jedno číslo, které zakladatelé zapomínají. Měsíční provozní náklady po launchi — ne jen infrastruktura, ale údržba kódu, bezpečnostní aktualizace, zákaznická podpora, bug fixy. Počítejte minimálně dvacet až třicet tisíc korun měsíčně na údržbu i u malého SaaS produktu. Bez toho vám aplikace do půl roku zastará a zákazníci začnou odcházet.

Timeline — co kdy čekat

Zakladatelé chtějí MVP za měsíc. Reálně to trvá dva až čtyři měsíce. A to za předpokladu, že máte jasnou specifikaci od prvního dne. Pokud specifikaci teprve tvoříte, přidejte měsíc.

Měsíc jedna: architektura, databázový model, autentizace, základní layout aplikace. Na konci prvního měsíce máte kostru — přihlásíte se, vidíte prázdný dashboard, máte strukturu v databázi.

Měsíc dva a tři: hlavní funkce. To, kvůli čemu zákazník přijde. Tady je osmdesát procent vývoje. Sem patří i billing integrace a základní nastavení účtu.

Měsíc čtyři: testování, opravy, onboarding, landing page, deployment do produkce. Beta verze pro první uživatele.

Co se dá paralelizovat: frontend a backend se dají vyvíjet současně, pokud máte jasně definované API kontrakty. Landing page a marketing web může vznikat paralelně s vývojem aplikace. Copywriting a dokumentace taky.

Co se nedá paralelizovat: billing integrace závisí na backendu. Testování závisí na hotových funkcích. Onboarding závisí na tom, že aplikace reálně funguje.

Jeden tip z praxe: netlačte na rychlost za cenu kvality v autentizaci a billingu. Chyba v přihlášení znamená, že se zákazník nedostane do aplikace. Chyba v billingu znamená, že vám nezaplatí. Oboje je fatální.

A počítejte s tím, že první verze nebude perfektní. Počítejte s iterací. První měsíc po launchi strávíte opravováním věcí, které jste v testování neodhalili, protože reální uživatelé dělají věci, které byste nikdy nečekali. To je normální. To není selhání. To je proces.

Chyby, které zabíjí SaaS projekty

Za poslední roky jsme viděli desítky SaaS projektů. Většina z nich nedopadla. Ne proto, že by nápad byl špatný. Ale proto, že zakladatelé udělali jednu z těchto chyb.

Stavění příliš mnoho před validací. Zakladatel stráví půl roku a milion korun vývojem. Pak zjistí, že o produkt nikdo nestojí. Řešení: prodávejte dřív, než máte produkt. Landing page, waitlist, ruční onboarding prvních zákazníků. Pokud nedokážete přesvědčit deset lidí, aby se zapsali na čekací listinu, nemáte produkt — máte hobby.

Špatný pricing model. Příliš levně a nepokryjete náklady. Příliš draze a nikdo nekoupí. Freemium a nemáte konverzi do placené verze. Nejčastější chyba v Česku: příliš nízká cena. Český SaaS se prodává za devět set korun měsíčně, zatímco identický americký produkt stojí devadesát dolarů. Nebojte se účtovat víc. Pokud váš produkt šetří firmě hodiny práce týdně, tisíc korun měsíčně je směšná částka.

Ignorování churnu. Churn je procento zákazníků, kteří každý měsíc odejdou. Pět procent měsíčně zní málo. Ale za rok vám odejde víc než polovina zákazníků. Pokud neměříte churn od prvního dne, nevidíte, jak rychle vám teče voda z nádrže. A hlavně nevíte proč.

Nemluvit s uživateli. Dashboard s metrikami je fajn. Ale žádná analytika vám neřekne, proč zákazník odešel. Proč nedokončil onboarding. Proč používá jen jednu funkci z deseti. Na to potřebujete mluvit s lidmi. Každý týden. Osobně nebo přes call. Zakladatelé, kteří tohle dělají, mají třikrát vyšší retenci. Není to přehánění.

Technický dluh od prvního dne. Spěch na MVP neznamená psát špatný kód. Znamená to psát méně kódu. Každý řádek, který napíšete, je řádek, který budete muset udržovat. Nejlepší kód je ten, který jste nemuseli napsat. Použijte hotové řešení pro autentizaci, pro billing, pro emaily. Pište vlastní kód jen tam, kde je vaše unikátní hodnota.

Šestá chyba, o které se mluví méně: zakladatel, který nedeleguje technická rozhodnutí. Máte skvělý byznysový instinkt, proto jste založili firmu. Ale pokud nemáte deset let zkušeností s vývojem software, nenechávejte si poslední slovo v architektonických rozhodnutích. Najděte technického partnera, kterému důvěřujete, a nechte ho rozhodovat o stacku, infrastruktuře a technickém dluhu. Vy rozhodujte o produktu, trhu a zákaznících. To je vaše práce.

Závěr: SaaS je maraton, ne sprint

Postavit SaaS platformu je jedno z nejnáročnějších podnikatelských rozhodnutí, které můžete udělat. Je to drahé, je to pomalé a většina pokusů skončí neúspěchem.

Ale ty, které uspějí, mají něco společného. Začaly malé. Validovaly rychle. Mluvily se zákazníky. A měly technického partnera, který rozuměl nejen kódu, ale i byznysu za ním.

Nemusíte rozumět každému technickému detailu v tomto článku. Musíte ale rozumět principům: začněte s jednou funkcí, validujte ji na reálných zákaznících, škálujte až když víte, že to funguje. Vše ostatní je optimalizace.

Plánujete vlastní SaaS produkt?

Pomůžeme vám s architekturou, výběrem stacku i stavbou prvního MVP. Neděláme powerpoint prezentace — píšeme kód, nasazujeme do produkce a iterujeme podle reálných dat.

Domluvte si konzultaci: calendly.com/exposethewealth/30min