Jak bych vybudoval SaaS – nájem, fakturace a co z něj dělá produkt

MVP odpovídá: dokončí někdo tuto práci? Odpověď SaaS: Bude mnoho společností nadále platit, abychom mohli provozovat jednu kódovou základnu pro všechny? Druhá otázka není „přidat Stripe a přihlásit se“. Je to pronájem, fakturace, onboarding a způsob, jak pomoci cizímu člověku ve 2:00 bez SSHingu do jeho dat.

Už jsem psal, jak bych vybral stack pro MVP. Toto je další vrstva: když je tvar firmy software jako služba, co bych skutečně vybudoval, v jakém pořadí a co bych odmítl zkopírovat z Linear nebo Salesforce v prvním měsíci.

1. Za prvé: je to skutečně SaaS?

Spousta „SaaS nápadů“ je systém na míru pro jednoho klienta s měsíční fakturou. To může být dobrý byznys. Není to SaaS. SaaS znamená jeden produkt, mnoho nájemců, samoobslužný nebo nenáročný prodej a náklady na přidání další společnosti se blíží nule – žádný další projekt.

• SaaS: mnoho organizací, stejné funkce, fakturace v produktu, dobu provozuschopnosti vlastníte vy.
• Vlastní software: jeden kupující, jedinečné pracovní postupy, fakturujete za požadavky na změny. Nepředstírejte, že se druhý klient „jen přihlásí“.
• Pokud první tři zákazníci potřebují vidličku, přestaňte ji nazývat SaaS. Prodávejte projekty, dokud nebude zřejmé, že se překrývají – pak produkt extrahujte.

2. Jednotkou produktu je pracovní prostor, nikoli uživatel

Doménu bych modeloval kolem organizace (pracovní prostor, tenant, účet – vyberte jedno slovo a ponechte si ho). Uživatelé patří do organizací. Data patří organizacím. Účty patří organizacím. Pokud začnete s „Uživatel má projekty“, strávíte šest měsíců hledáním týmů, pozvánek a „kdo platí“.

• Organizace má plán, fakturační e-mail a stav: zkušební, aktivní, po splatnosti, zrušeno.
• Členství je řádkové: uživatel + organizace + role (na začátek stačí vlastník, admin, člen).
• Každá obchodní tabulka má org_id. Dotazy bez org_id jsou chyby, nikoli zkratky.
• Pozvánky před „vytvořit pro ně uživatele“. Zašlete e-mail, přijměte, přistaňte ve správném pracovním prostoru.

3. Nájem: sdílená databáze, přísná izolace

Prvních SaaS bych neotevíral Postgres na zákazníka. Použil bych jednu databázi, org_id na každém řádku a hloubkovou obranu, aby se z vynechání WHERE nemohlo stát únik dat. Databáze na nájemce je pro regulovanou izolaci nebo hlučné sousedy, které jste již změřili - ne pro nájemce číslo čtyři.

• Zabezpečení na úrovni řádků nebo ekvivalentní pomocník dotazu, který vždy vkládá org_id z relace – nikoli z těla klienta.
• ID, která nelze uhodnout (UUID). Sekvenční /org/12/invoices/4 je pozvánka.
• Úložiště souborů s předponou org_id, podepsané adresy URL, nikdy veřejný sektor „všechna nahraná videa“.
• Schéma-na-tenanta nebo DB-na-tenanta pouze v případě, že si to vynutí smlouva, kontrolní seznam shody nebo skutečný hlučný soused. Migrace přes 200 schémat jsou produktem, který jste nechtěli.

4. Fakturace je funkce, nikoli plugin, který přidáte později

Pokud nikdo nemůže zaplatit, nemáte SaaS. Checkout bych dal do kritické cesty za týden dva, i když je rest aplikace tenká. Fáze „fakturujeme ručně“ je povolena pro prvních pět designérských partnerů – poté musí karta fungovat.

• Stripe Fakturace (nebo procesor, který váš první trh skutečně používá): produkty, ceny, zákaznický portál, webhooky. Neukládejte čísla karet. Nepište upomínací motor.
• Jeden nebo dva plány, ne sedm. Soud s jasným koncem. Po vyzkoušení: pouze pro čtení nebo pevný blok – vyberte jeden a řekněte to v uživatelském rozhraní.
• Cena, čemu zákazníci rozumí: místa, projekty nebo měsíční objem. Účtování za použití je výkonné a snadno se zmýlí; začněte se sedadlem nebo plochým plánem, dokud nebudete vědět, co je to „použití“.
• Webhooky jsou zdrojem pravdy pro „jsou placené?“ Vaše databáze zrcadlí Stripe (nebo pádlo). Cron, který odhaduje, jak uzamknete platícího zákazníka.

5. Zásobník, který bych použil (a jak se liší od MVP webu)

Výchozí nastavení webu stále platí: Next.js, TypeScript, Tailwind, Postgres. SaaS přidává několik kousků, které marketingový web nepotřebuje – a stále nepotřebuje síť služeb.

• Auth, který rozumí organizacím: Clerk, WorkOS, Auth.js plus vaše tabulka členství – ani jeden globální příznak „přihlášeno“.
• Úlohy na pozadí prvního dne, pokud je něco pomalé nebo opakovatelné: e-maily, Stripe webhooky, exporty, LLM hovory. Jednoduchá fronta (Inngest, Trigger.dev nebo pracovník na VPS) překonává setTimeout ve funkci bez serveru.
• Transakční e-mail od první minuty: pozvánka, potvrzení, „vaše zkušební období končí v pátek“. Pokud tato pošta nedorazí, produkt se cítí mrtvý.
• Příznaky funkcí pro plány (can_export, seat_limit), nikoli if (org.plan === "pro") rozptýlené v padesáti souborech.
• Hosting: Vercel plus hostovaný Postgres je v pořádku, dokud pracovník nebo bydliště neřeknou jinak. Jeden region stačí. Víceregiony jsou pozdějším problémem.

6. Onboarding je produkt na první hodinu

Prázdné SaaS dashboardy se nepřevádějí. První relaci bych navrhl jako práci, nikoli prohlídku: vytvořte pracovní prostor, importujte nebo zadejte první skutečný záznam, pozvěte jednoho spoluhráče, podívejte se na jeden výsledek. Popisky nad prázdnou tabulkou se nezařazují.

• Ukázkový pracovní prostor je povolen, pokud je jasně falešný a na jedno kliknutí vás dělí od „začít s mými údaji“.
• Metrika aktivace: dokončili hlavní úlohu jednou, nikoli „zaregistrovali se“. Sledujte to. Ukaž to.
• Nastavení může být ošklivé. Prázdný stav hlavní obrazovky nemůže.

7. Ops: jak budete podporovat lidi, které jste nikdy nepotkali

V den, kdy platící organizace napíše „Nevidím své faktury“, potřebujete cestu, která není produkčním SSH. Tenkou interní adminku bych přidal před desátým zákazníkem, ne po prvním incidentu.

• Správce: najít organizaci, zobrazit plán a poslední webhook, vydávat se za osobu pouze pro čtení, znovu odeslat pozvánku. Zkontrolujte to zosobnění.
• Protokoly s org_id a ID požadavku. „Nepovedlo se to“ bez nájemce není čára protokolu, je to pokrčení ramen.
• Zálohy, které jste jednou obnovili. Na začátku stačí noční; netestované zálohy jsou příběh, který si vyprávíte sami.
• Stavová stránka může počkat. E-mail „jsme mimo, tady je to, co víme“ nemůže.

8. Co bych nepostavil za rok jedna

Big SaaS je muzeum funkcí, které se později vyplatily. Kopírování muzea je způsob, jak vám chybí jediná práce.

• SSO, SCIM a 40stránkový bezpečnostní dotazník, dokud na nich nebude zablokován skutečný obchod. Pak se stanou sprintem, ne vedlejším úkolem.
• Veřejné API a tržiště integrací. Jeden Zapier nebo export CSV často odblokuje stejného kupujícího.
• Vlastní domény pro nájemce, white-label a téma studio. Nahrání loga stačí pro většinu raných B2B.
• AI všude. Jedno místo, kde je jazyk práce (hledání, koncepty, extrakce) se schématem a zúčtovatelným měřičem. Ne na každé obrazovce chatovací bublina.

9. Sekvence, kterou bych skutečně dodržel

Stejná poctivost kalendáře jako MVP, s milníky ve tvaru SaaS. Pokud týden nemá nájemce, žádnou mzdu nebo práci, není to SaaS týden.

• Týden 0: pojmenujte práci, kupujícího, plán, počet zabití (např. pět placených organizací za 90 dní nebo se zastavíme). Bez cílů na stránce.
• Týdny 1-2: organizace + členství + jedna šťastná cesta v produkci + Stripe testovací režim. Testy izolace: uživatel A nesmí vidět uživatele B.
• Týdny 3-4: živá fakturace, pozvánky, e-maily, přihlášení do prázdného stavu, tenký admin. Dejte to před jmenované společnosti, ne „internet“.
• Dny 30-90: aktivace hodinek a důvody pro ukončení. Přidejte jednu integraci nebo sestavu, za kterou platí. Nepřidávejte druhý produkt.

Závěr: pronajměte si práci, ne platformu

Postavil bych SaaS stejným neokoukaným způsobem jako MVP plus části, díky nimž mnoho společností sdílí jeden systém: pracovní prostor, účet, zeď mezi nájemci, první hodina, která není prázdná, a admin, takže podpora není root shell. Zásobník může zůstat nudný. Produkt nemůže zůstat neurčitý.

Pokud máte workflow několik společností, které vám již platí za opakování a chcete to jako produkt místo hromady vlastních nasazení - napište přes sekci kontakty. Můžeme pojmenovat model nájemce, první plán a řez, který zabírá kartu, aniž by předstíral, že je Salesforce.