SaaS

Co jsem se naučil při budování SaaS produktu od nuly

· 11 min čtení
Co jsem se naučil při budování SaaS produktu od nuly

Na internetu najdete stovky článků o tom, jak postavit SaaS. Většina z nich vypadá takhle: „Najděte problém, validujte nápad, vytvořte MVP, škálujte.” Zní to jednoduše. V praxi to jednoduché není.

Jmenuju se Jakub Dostál a za posledních pár let jsem se podílel na vývoji několika SaaS produktů — od fakturačního systému s více než 100 000 uživateli po menší oborové nástroje. Tenhle článek není návod. Je to seznam věcí, které jsem se naučil za cenu vlastních chyb, promarněného času a občas i zbytečně vyhozených peněz klientů.

MVP neznamená „špatný produkt”

Tohle je první a nejdůležitější lekce. Minimum Viable Product neznamená minimální kvalitu. Znamená minimální rozsah.

Rozdíl je zásadní. Když uděláte produkt, který má tři funkce, ale ty tři funkce fungují spolehlivě, rychle a intuitivně — máte MVP. Když uděláte produkt, který má dvacet funkcí a žádná z nich pořádně nefunguje — máte problém.

U fakturujzdarma.cz bylo první MVP brutálně jednoduché: vystavit fakturu, odeslat ji emailem, zobrazit seznam faktur. To bylo všechno. Žádné reporty, žádné napojení na účetní systémy, žádná mobilní aplikace. Jen core funkce, která musela fungovat bezchybně.

Pár pravidel, které se mi osvědčila:

  • Jedna věc musí být výborná. Ne dobrá — výborná. To je důvod, proč se uživatel vrátí.
  • Zbytek může chybět. Lidi tolerují chybějící funkce mnohem líp než nefunkční funkce.
  • Feedback sbírejte od prvního dne. Ne ankety, ne focus groups — sledujte, co uživatelé skutečně dělají.

Technologický stack rozhoduje víc, než si myslíte

Existuje fráze „na technologii nezáleží, důležitý je produkt.” Je to pravda jen z poloviny.

U jednoduchého webu nebo landing page to platí. U SaaS, který má fungovat roky, škálovat se a být udržitelný s malým týmem — na stacku záleží hodně.

Moje volba technologií pro SaaS produkty:

Go na backendu — ne proto, že je módní, ale proto, že je předvídatelný. Kompilovaný, staticky typovaný, s minimální spotřebou paměti. Když váš SaaS běží na jednom serveru a platíte za RAM, Go vám ušetří reálné peníze. Jeden Go server zvládne to, na co byste v Node.js potřebovali tři.

PostgreSQL jako databáze — u SaaS s finančními daty nechcete experimentovat. Potřebujete ACID transakce, solidní indexy a zálohy, na které se můžete spolehnout. PostgreSQL tohle dodává dekády.

SvelteKit na frontendu — rychlost renderingu a malé bundle size. Když uživatel pracuje v aplikaci hodiny denně, každých 100 ms, o které zrychlíte interakci, se násobí tisíckrát.

To neznamená, že tohle je jediný správný stack. Ale je to stack, u kterého vím, co očekávat. A u SaaS je předvídatelnost cennější než novost.

Multi-tenancy je těžší, než vypadá

Skoro každý SaaS potřebuje multi-tenancy — tedy oddělení dat jednotlivých zákazníků. A skoro každý tým to na začátku podcení.

Existují tři základní přístupy:

  1. Sdílená databáze, sdílená schémata — nejlevnější, nejrizikovější. Jeden špatný dotaz a vidíte cizí data.
  2. Sdílená databáze, oddělená schémata — kompromis. Lepší izolace, ale složitější migrace.
  3. Oddělené databáze — nejbezpečnější, nejdražší. Každý tenant má svou databázi.

U většiny projektů volím první přístup se striktními bezpečnostními pravidly. Každý databázový dotaz musí obsahovat tenant_id. Žádné výjimky. Kontroluji to na úrovni middleware, ne na úrovni aplikační logiky — protože aplikační logiku lidi obcházejí, middleware ne.

// Každý request automaticky dostane tenant context
func TenantMiddleware() fiber.Handler {
    return func(c *fiber.Ctx) error {
        tenantID := extractTenantID(c)
        c.Locals("tenant_id", tenantID)
        return c.Next()
    }
}

Tohle zní triviálně, ale v praxi je to kritické. Jeden únik dat mezi tenanty a máte existenční problém.

Platby: implementujte je dřív, než myslíte

Většina vývojářů (včetně mě) odkládá platební bránu co nejdéle. „Nejdřív vybudujeme hodnotu, pak monetizujeme.” Zní to logicky. V praxi je to past.

Proč? Protože platba mění chování uživatelů. Lidi, kteří platí, se chovají úplně jinak než lidi, kteří používají produkt zadarmo. Jinak reportují bugy, jinak žádají o funkce, jinak komunikují.

Pokud budujete produkt na základě feedbacku od neplatících uživatelů, budujete špatný produkt. Nebo přesněji — budujete produkt pro lidi, kteří nikdy platit nebudou.

Implementujte platby co nejdřív. I když je to jen základní integrace se Stripe. I když první měsíce budete mít nula příjmů. Důležité je vidět konverzi — kolik lidí je ochotno zaplatit. To číslo vám řekne víc o vašem produktu než jakákoli metrika engagementu.

Monitoring není luxus

Tohle jsem se naučil tvrdě. V prvních měsících jednoho projektu jsem neměl žádný seriózní monitoring. Aplikace běžela, logy se zapisovaly do souboru, občas jsem se podíval.

Pak jednou v noci vypadla databáze. Zjistil jsem to ráno. Osm hodin výpadku. Uživatelé nemohli vystavovat faktury. Někteří z nich měli deadline na odeslání faktur svým klientům.

Od té doby mám na každém SaaS projektu:

  • Health check endpoint — jednoduchý ping na /health, který ověří připojení k databázi i Redis
  • Alerting — pokud health check selže dvakrát za sebou, dostanu notifikaci. Ne email — push notifikaci na telefon.
  • Metriky — response time, error rate, CPU/memory usage. Ne proto, že bych je denně sledoval, ale proto, že když se něco pokazí, mám historii.
  • Structured logging — JSON logy s request ID, tenant ID, user ID. Když potřebuju zjistit, co se stalo, umím to dohledat za minuty, ne za hodiny.

U automatizace firemních procesů tohle platí dvojnásob — automatizovaný systém, který tiše selže, je horší než žádný systém.

Onboarding rozhoduje o úspěchu

Můžete mít nejlepší produkt na světě. Pokud uživatel nepochopí, jak ho použít, během prvních pěti minut odejde. A nevrátí se.

Co funguje:

  • Prázdný stav není prázdný. Když se uživatel poprvé přihlásí, nevidí prázdnou stránku. Vidí ukázkový obsah, průvodce, nebo alespoň jasnou instrukci, co udělat jako první.
  • Jeden krok, ne deset. Nebuďte Jira. Nenuťte uživatele vyplnit dvacet polí, než může udělat první akci. Minimum informací na začátku, zbytek si vyžádejte později.
  • Ukaž, neříkej. Interaktivní průvodce funguje líp než dokumentace. Video funguje líp než text. Ale nejlíp funguje produkt, který je tak intuitivní, že žádného průvodce nepotřebuje.

U fakturujzdarma.cz jsme testovali onboarding opakovaně. Měřili jsme, kolik uživatelů vystaví první fakturu do 10 minut od registrace. Na začátku to bylo kolem 40 %. Dneska je to přes 70 %. Rozdíl nebyl v produktu — byl v tom, jak jsme uživatele provedli prvními kroky.

Nebojte se smazat funkce

Tohle je možná nejtěžší lekce. Přidávat funkce je snadné. Mazat je bolí.

Ale každá funkce má cenu. Cenu údržby, cenu testování, cenu v kognitivní složitosti pro uživatele. Když máte v produktu funkci, kterou používá 2 % uživatelů, ale zabírá 15 % vašeho času na údržbu — smazte ji.

My jsme u jednoho projektu odstranili celý modul pro pokročilé reporty. Tři měsíce práce. Nikdo ho nepoužíval. Bylo to bolestivé rozhodnutí, ale po jeho odstranění se zjednodušil kód, zrychlily se testy a tým se mohl soustředit na věci, které skutečně fungovaly.

Pravidlo, které se mi osvědčilo: pokud funkci nemůžete vysvětlit jednou větou, je příliš složitá. A pokud ji nepoužívá aspoň 20 % aktivních uživatelů, zvažte její odstranění.

Cena je součást produktu

Pricing není marketing — je to produktové rozhodnutí. Špatně nastavená cena zabije dobrý produkt rychleji než špatný kód.

Věci, které jsem se naučil o cenotvorbě:

  • Freemium funguje jen s velkou bází uživatelů. Pokud nemáte tisíce uživatelů měsíčně, freemium vás jenom zatíží infrastrukturou bez příjmů.
  • Příliš nízká cena je horší než příliš vysoká. Nízká cena přitahuje problematické zákazníky a signalizuje nízkou hodnotu.
  • Tři plány stačí. Základní, profesionální, enterprise. Víc než tři plány mate uživatele.
  • Roční platby řeší cashflow. Nabídněte slevu za roční platbu. Získáte peníze dopředu a snížíte churn.

Co bych udělal jinak

Kdybych začínal znovu, udělal bych tři věci jinak.

Zaprvé — investoval bych do testů od začátku. Ne proto, že testy jsou „správná praxe”. Proto, že bez testů se bojíte měnit kód. A SaaS, ve kterém se bojíte měnit kód, je mrtvý SaaS.

Zadruhé — řešil bych platby od prvního měsíce. Viz výš. Čím dřív víte, jestli jsou lidi ochotni platit, tím líp.

Zatřetí — najal bych designéra dřív. Vývojáři (včetně mě) mají tendenci podceňovat UX. „Funguje to, ne?” Jo, funguje. Ale lidi to nechtějí používat, protože to vypadá jako backend admin panel z roku 2010.

Shrnutí bez pozlátek

Budování SaaS je řemeslo. Není to sprint — je to maraton, kde na konci nikdo nečeká s medailí. Odměna je fungující produkt, spokojení uživatelé a vědomí, že jste vybudovali něco, co má hodnotu.

Pokud uvažujete o vlastním SaaS produktu a hledáte někoho, kdo má zkušenost nejen s vývojem, ale i s provozem v produkci — rád se o tom pobavím. Žádné sliby, jen upřímný pohled na to, co vás čeká.

Jakub Dostál, NeonByte s.r.o.