Jak vybrat technologický stack pro váš první SaaS: upřímný průvodce pro zakladatele

Zeptejte se deseti vývojářů, jaký technologický stack byste měli použít pro svůj první SaaS, a dostanete patnáct odpovědí, tři z nich pronesené s jistotou náboženství. Většina těch odpovědí je správná — pro toho, kdo je dává. Žádná z nich není o vás, o tom, na jak dlouho vám vystačí peníze, ani o zákaznících, které jste ještě nepodepsali. Pokud jste zakladatel, který na tohle rozhodnutí zírá a je mu lehce nevolno, tady je to, co nikdo neřekne nahlas: na stacku záleží mnohem méně, než vás přiměli věřit, a těch pár způsobů, jak na něm záleží, nejsou ty, o které se lidé hádají online.

Pomohl jsem slušné řadě zakladatelů poprvé přejít od prezentace k produktu, za který skuteční lidé platí. Skoro nikdo z nich nebyl technik. Skoro všichni dorazili poté, co už do sebe nasáli děsivé množství folklóru o stacku — že potřebují mikroslužby, že jeden framework je „mrtvý", že špatná volba je odsoudí k zániku. A skoro pokaždé se stack ukázal jako jedno z nejméně podstatných rozhodnutí, která ten rok udělali. Co projekty zabilo, byl rozsah, nejasná odpovědnost a krásné vytváření špatné věci. Nikdy ne framework.

Tohle je tedy průvodce, který těmto zakladatelům dávám, než napíšeme jediný řádek kódu. Neřekne vám, abyste použili jeden konkrétní stack, protože kdokoli vám to slíbí, aniž zná vaše podnikání, vám něco prodává. Místo toho vám dá způsob, jak přemýšlet — takže ať si vyberete cokoli, nebo ať vám tým navrhne cokoli, dokážete to prověřit jako dospělý člověk, místo abyste nervózně přikyvovali.

Proč se tohle rozhodnutí zdá těžší, než je

Otázka stacku se zdá obrovská, protože je to první zdánlivě nevratná volba, kterou děláte, a je zabalená do jazyka, kterým nemluvíte. Slova jako Postgres, React, Kubernetes, serverless se rozhazují, jako by výběr mezi nimi byl jako výběr základů budovy — uděláte to špatně a celé se to zhroutí.

Software ale není budova. Mnohem víc se podobá kuchyni, kterou můžete přestavovat, zatímco v ní pořád vaříte. Úspěšné firmy přepisují části svého stacku neustále; verze produktu, která najde svých prvních sto zákazníků, skoro nikdy není verze, která obsluhuje prvních sto tisíc. Cílem vašeho prvního stacku není vydržet navždy. Je to nechat vás stavět, měnit a vydávat dost rychle na to, abyste zjistili, jestli to vůbec někdo chce. To je úplně jiná — a mnohem nižší — laťka než „dokonalý na další desetiletí".

Jakmile to přijmete, tlak klesne na polovinu. Už se nesnažíte předpovídat budoucnost. Snažíte se udělat rozumnou, vratnou sázku, která vás dovede k fungujícímu produktu a platícím uživatelům. A rozumné sázky jsou něco, co netechnický zakladatel rozhodně dokáže posoudit.

Co vlastně „stack" je, jednoduše řečeno

Než se o čemkoli rozhodnete, pomáhá to slovo odtajnit. Technologický stack je prostě soubor nástrojů použitých k vytvoření a provozu vašeho softwaru. Můžete si ho představit ve čtyřech vrstvách a žádné z nich nemusíte do hloubky rozumět — stačí vědět, že existují.

• Frontend — to, co uživatelé vidí a na co klikají ve svém prohlížeči nebo aplikaci. Tahle část je ta, podle které vás všichni soudí.
• Backend — logika a pravidla běžící na serveru: kdo co smí dělat, co se stane, když to udělá, jak se pohybují peníze.
• Databáze — kde vaše informace skutečně žijí: uživatelé, objednávky, předplatná, všechno, co by vás zničilo ztratit.
• Infrastruktura — servery a služby, které drží všechno výše uvedené online, zazálohované a dostupné ve tři ráno.

Když někdo řekne „použijeme moderní JavaScriptový stack" nebo „Rails na Postgresu", popisuje volby napříč těmito čtyřmi vrstvami. Nic víc. Každý SaaS, od dvoučlenného vedlejšího projektu po veřejnou firmu, je nějaká verze těchto čtyř věcí naskládaných na sebe. Velkolepě znějící architektonické diagramy jsou jen tohle, nakreslené s více obdélníky.

Věci, na kterých opravdu záleží (a věci, na kterých ne)

Tady se většina rad ohledně stacku míjí: optimalizuje na věci, které neovlivní vaše první dva roky, a ignoruje věci, které ano. Dovolte mi být u obou seznamů přímý.

Na čem opravdu záleží

Kdo to dokáže postavit a udržovat. Jediný největší faktor není technologie — jsou to lidé. Nejlepší stack pro vás je ten, ve kterém váš tým (nebo partner, kterého najmete) skutečně dokáže plynule pracovat, dnes. „Dokonalý" stack, kterému rozumí jen jeden vzácný specialista, je horší volba než nudný stack, který zvládne převzít jakýkoli schopný vývojář. Nábor a kontinuita pokaždé porazí teoretickou eleganci.

Jak rychle dokážete věci měnit. Zpočátku se budete v produktu neustále mýlit. Skutečným úkolem stacku je udělat změnu názoru levnou. Vyzrálé, dobře zdokumentované nástroje s velkými komunitami vám umožní pohybovat se rychle, protože odpovědi na vaše problémy už existují. Nástroje na špici vás udělají tím, kdo objevuje chyby.

Jestli na to dokážete nabírat. Vyberte něco neznámého a svážete svou budoucnost s tím, kdo to postavil. Vyberte něco běžného a nudného a vždycky najdete dalšího vývojáře, další agenturu, dalšího člověka, který to převezme. Nudné je přednost, když na tom závisí vaše podnikání.

Na čem záleží mnohem méně, než lidé říkají

Surový výkon a „škálování". Vy nemáte problém se škálováním. Máte problém zatím-to-nikdo-nepoužívá, což je opačný problém. Architektury navržené pro miliony uživatelů vás zpomalí, když máte jedenáct. Slavné firmy, které napodobujete, postavily nejdřív jednoduchou verzi a přestavěly ji později, financováno úspěchem. Tak byste měli postupovat i vy.

Který konkrétní framework letos „vyhrává". Frameworky stoupají a klesají v módním cyklu, který nemá skoro nic společného s tím, jestli vám dobře postaví váš fakturační SaaS. Kterákoli z mainstreamových, široce používaných možností tu práci odvede. Trend je šum; vyberte z nudného populárního středu a jděte dál.

Proč „nudná" technologie obvykle vyhrává

Mezi zkušenými staviteli panuje tichá moudrost, kterou nováčci považují za zklamání: nejlepší technologie pro nový byznys je obvykle ta nudná, ověřená, trochu nemoderní. Ne proto, že nové nástroje jsou špatné, ale protože každá volba, kterou uděláte, utratí omezený rozpočet novosti — počet neznámých, nepodporovaných, překvapivých věcí, které váš malý tým zvládne najednou.

Utraťte ten rozpočet na to, co dělá váš byznys výjimečným — na samotný produkt, na vhled, který máte jen vy. Neutrácejte ho za databázi, o které nikdo neslyšel, jen abyste se cítili moderní. Nudný, vyzrálý stack znamená, že problémy už byly vyřešeny, dokumentace existuje, nábor je snadný a nástroj příští rok nezmizí, až jeho jediný správce ztratí zájem. Nudný vám umožní vložit všechno své nadšení tam, kde se vyplácí: do zákazníka.

Tady taky umělá inteligence trochu mění obrázek — a ne tak, jak naznačuje humbuk. AI asistenti pro kódování jsou dramaticky lepší u nudných, populárních technologií, protože byli trénováni na desetiletí veřejných odpovědí o nich. Vyberte mainstreamový stack a váš tým (a vaše nástroje) dostanou rychlejší pomoc zdarma. Vyberte něco exotického a jste na to sami přesně tehdy, kdy si to můžete nejméně dovolit.

Metoda rozhodování, kterou opravdu můžete použít

Dost principů. Tady je konkrétní způsob, jak dospět k rozhodnutí, ať už vybíráte sami, zadáváte zadání freelancerovi, nebo posuzujete, co navrhuje agentura. Nic z toho po vás nevyžaduje psát kód — jen ptát se na správné věci a zvážit odpovědi.

1. 1
   Vyjděte z týmu, ne z technologie

   Ptejte se: kdo to bude příští dva roky stavět a udržovat? Cokoli už dobře umí, je vaše silná výchozí volba. Měnit stack kvůli honbě za trendem zřídka porazí plynulost.
2. 2
   Výchozí volbou ať je mainstream a osvědčené

   Vybírejte z populárního, dobře zdokumentovaného středu každé vrstvy. Pokud rychle nenajdete tutoriály, pracovní nabídky a velké komunity pro nástroj, berte to jako varování, ne jako přednost.
3. 3
   Optimalizujte na změnu, ne na škálování

   Upřednostněte volbu, která dělá úpravy produktu levné a rychlé. V produktu se budete opakovaně mýlit — úkolem stacku je udělat mýlení přežitelným.
4. 4
   Udržte architekturu co nejjednodušší

   Jedna databáze. Jeden backend. Jeden frontend. Žádné mikroslužby, žádné chytré distribuované cokoli, dokud vás k tomu nedonutí skutečný, změřený problém. Jednoduchost je cíl, ne kompromis.
5. 5
   Napište si, proč jste to vybrali

   Jeden odstavec: kdo to staví, co jste vybrali a co by se muselo změnit, abyste to přehodnotili. Tahle poznámka vás zachrání před opakovaným přerozhodováním pokaždé, když si někdo přečte vyhraněný názor.

Pokud se neřídíte ničím jiným, řiďte se kroky jedna a čtyři. Stavte s lidmi, které máte, na nejjednodušší architektuře, která funguje. Tahle kombinace tiše předchází dvěma způsobům selhání, které potápí většinu prvních SaaS produktů: nikdo, kdo to dokáže udržovat, a systém příliš složitý na svou velikost.

Otázky, které položit komukoli, kdo navrhuje stack

Většina zakladatelů stack nevybírá sama — vývojář, agentura nebo kamarád CTO nějaký navrhne. Nemusíte technologii ověřovat sami. Musíte položit hrstku otázek a poslouchat, jak odpovídají. Sebevědomé odpovědi prostým jazykem jsou dobré znamení. Obranný žargon ne.

• „Proč tohle, a ne nudná populární možnost?" — dobrá odpověď je o vašich konkrétních potřebách, ne o tom, co je trendy.
• „Kdyby vás srazil autobus, jak snadno by to mohl převzít někdo jiný?" — odpověď prozradí, jak vzácná a riziková volba je.
• „Jaká je nejjednodušší verze téhle architektury, která ještě funguje?" — sledujte, jestli sahají po jednoduchosti, nebo po složitosti.
• „Jak snadné bude najmout na tohle dalšího vývojáře?" — běžné dovednosti znamenají zdravý trh; exotické dovednosti znamenají závislost.
• „Co se stane, až budeme za tři měsíce potřebovat změnit klíčovou funkci?" — chcete slyšet, že změna je levná, ne obávaná.

Časté pasti, které vypadají jako dobré nápady

Pár vzorců se objevuje tak často, že stojí za pojmenování, protože každý z nich v dané chvíli působí zodpovědně a později vás draho stojí.

Stavět na škálování, které nemáte. Nutkání „udělat to pořádně" vede zakladatele k tomu, aby navrhovali pro miliony uživatelů dřív, než jich mají deset. Každý kousek téhle přípravy na budoucnost je složitost, kterou platíte teď, časem a penězi, abyste řešili problém, který možná nikdy nepřijde. Stavte pro dalších sto uživatelů. Přearchitektujte, až to růst učiní nutným — a ať je to příjemný problém.

Honit nejnovější věc. Lesklý framework vydaný minulý měsíc nemá žádnou historii, tenkou dokumentaci a malou komunitu. Budete trávit noci laděním nástroje místo stavění produktu. Nechte první adoptéry být ostatní; vy máte spustit byznys.

Zadat to nejlevnějšímu, na čemkoli, co preferuje on. Nejnižší nabídka často přichází s neznámým stackem, který zná jen ten jeden tým. V den, kdy se rozejdete, se váš produkt stane ostrovem, ke kterému se nikdo jiný nedostane. Levné na začátku, zničující později. Trvejte na mainstreamové, najímatelné technologii, i když zadáváte externě — zvlášť když zadáváte externě.

Kdy je opravdu čas přehodnotit váš stack

Nic z toho neznamená „nikdy neměňte". Znamená to měnit ze skutečných důvodů, změřených, ne vymyšlených. Poznáte, že je opravdu čas nechat váš stack vyvíjet se, když se objeví konkrétní signály — ne když vás nějaký blogový příspěvek znervózní.

Všimněte si vzorce: skutečné důvody jsou o změřené bolesti ve vašem reálném byznysu. Falešné důvody jsou o módě, srovnávání a neklidu. Když se skutečný signál objeví, měníte jeden kus po druhém — ne celý stack v hrdinském přepisu, který všechno na půl roku zastaví. Evoluce, ne revoluce.

Časté otázky