Hogyan válasszon technológiai stacket az első SaaS-éhez: őszinte útmutató alapítóknak

Kérdezzen meg tíz fejlesztőt, milyen technológiai stacket használjon az első SaaS-éhez, és tizenöt választ fog kapni, hármat közülük vallásos meggyőződéssel előadva. A legtöbb válasz helyes — annak, aki adja. Egyik sem Önről szól, sem a pénze kifutási idejéről, sem azokról az ügyfelekről, akiket még nem szerzett meg. Ha Ön alapító, aki erre a döntésre mered, és kissé felfordul a gyomra, íme, amit senki sem mond ki hangosan: a stack sokkal kevésbé számít, mint amennyire elhitették Önnel, és az a néhány mód, ahogyan számít, nem az, amin az emberek online vitatkoznak.

Jó néhány első alkalommal alapítónak segítettem eljutni egy diasoros bemutatótól egy olyan termékig, amelyért valódi emberek fizetnek. Szinte egyikük sem volt műszaki. Szinte mindegyikük úgy érkezett, hogy már magába szívott ijesztő mennyiségű stackfolklórt — hogy szükségük van mikroszolgáltatásokra, hogy egy adott keretrendszer „halott", hogy a rossz választás a vesztüket okozza. És szinte minden alkalommal a stack lett az egyik legkevésbé lényeges döntés, amelyet abban az évben hoztak. Ami a projekteket megölte, az a hatókör, a tisztázatlan felelősség és a rossz dolog szép kivitelezése volt. Soha nem a keretrendszer.

Tehát ez az az útmutató, amelyet ezeknek az alapítóknak adok, mielőtt egyetlen sornyi kódot írnánk. Nem fogja megmondani, hogy egy adott stacket használjon, mert aki ezt megígéri anélkül, hogy ismerné a vállalkozását, az elad Önnek valamit. Ehelyett gondolkodásmódot ad — hogy bármit is válasszon, vagy bármit is javasoljon a csapata, felnőtt módjára ellenőrizhesse, ahelyett hogy idegesen bólogatna.

Miért tűnik ez a döntés nehezebbnek, mint amilyen

A stackkérdés azért tűnik óriásinak, mert ez az első, visszafordíthatatlannak hangzó választása, és olyan nyelvbe van burkolva, amelyet nem beszél. Az olyan szavakat, mint a Postgres, React, Kubernetes, serverless, úgy dobálják, mintha a köztük való választás olyan lenne, mint egy épület alapjának kiválasztása — rosszul csinálja, és az egész összeomlik.

De a szoftver nem épület. Sokkal inkább egy konyhához hasonlít, amelyet átépíthet, miközben még főz benne. A sikeres cégek folyamatosan újraírják a stackjük részeit; egy termék azon változata, amely megtalálja az első száz ügyfelét, szinte sosem az a változat, amely az első százezret szolgálja ki. Az első stackjének célja nem az, hogy örökké tartson. Az, hogy elég gyorsan engedjen építeni, változtatni és kiadni ahhoz, hogy megtudja, akarja-e ezt egyáltalán valaki. Ez teljesen más — és sokkal alacsonyabb — mérce, mint a „tökéletes a következő évtizedre".

Amint ezt elfogadja, a nyomás a felére csökken. Már nem a jövőt próbálja megjósolni. Egy ésszerű, visszafordítható fogadást próbál tenni, amely egy működő termékhez és fizető felhasználókhoz vezet. Az ésszerű fogadásokat pedig egy nem műszaki alapító egészen biztosan képes értékelni.

Mi is valójában a „stack", közérthetően

Mielőtt bármiről döntene, segít leleplezni a szót. A technológiai stack egyszerűen a szoftvere felépítéséhez és futtatásához használt eszközök összessége. Négy rétegben gondolhat rá, és egyiket sem kell mélyen értenie — csak tudnia kell, hogy léteznek.

• A frontend — amit a felhasználók látnak és amire kattintanak a böngészőjükben vagy alkalmazásukban. Ez az a rész, amely alapján mindenki megítéli Önt.
• A backend — a kiszolgálón futó logika és szabályok: ki mit tehet, mi történik, amikor megteszi, hogyan mozog a pénz.
• Az adatbázis — ahol az információi valójában élnek: felhasználók, rendelések, előfizetések, minden, aminek elvesztése letaglózná.
• Az infrastruktúra — a kiszolgálók és szolgáltatások, amelyek a fentieket online, biztonsági mentéssel ellátva és hajnali háromkor is elérhetően tartják.

Amikor valaki azt mondja, „modern JavaScript stacket fogunk használni" vagy „Rails Postgresen", akkor választásokat ír le e négy réteg mentén. Ennyi az egész. Minden SaaS, egy kétfős mellékprojekttől egy tőzsdén jegyzett cégig, e négy dolog valamilyen, egymásra rakott változata. A nagyszabásúan hangzó architektúradiagramok csak ennyik, csak több dobozzal rajzolva.

Ami valójában számít (és ami nem)

Itt téved el a legtöbb stacktanács: olyan dolgokra optimalizál, amelyek nem érintik az első két évét, és figyelmen kívül hagyja azokat, amelyek igen. Hadd legyek nyíltan őszinte mindkét listával kapcsolatban.

Ami valóban számít

Ki tudja megépíteni és karbantartani. Az egyetlen legfontosabb tényező nem a technológia — hanem az emberek. Az Önnek legjobb stack az, amelyben a csapata (vagy a partner, akit felvesz) valóban, folyékonyan tud dolgozni, már ma. Egy „tökéletes" stack, amelyet csak egyetlen ritka szakember ért, rosszabb választás, mint egy unalmas, amelyet bármely hozzáértő fejlesztő át tud venni. A toborzás és a folytonosság minden alkalommal legyőzi az elméleti eleganciát.

Milyen gyorsan tud dolgokat változtatni. Az elején folyamatosan tévedni fog a termékében. A stack valódi feladata, hogy olcsóvá tegye a véleményváltoztatást. Az érett, jól dokumentált, nagy közösségekkel rendelkező eszközök gyors haladást engednek, mert a problémáira a válaszok már léteznek. A legmodernebb eszközök Önt teszik azzá, aki felfedezi a hibákat.

Tud-e rá toborozni. Válasszon valami homályosat, és a jövőjét ahhoz köti, aki megépítette. Válasszon valami megszokottat és unalmasat, és mindig megtalálja a következő fejlesztőt, a következő ügynökséget, a következő embert, aki átveszi. Az unalmas előny, ha a vállalkozása múlik rajta.

Ami sokkal kevésbé számít, mint ahogy mondják

A nyers teljesítmény és a „skála". Önnek nincs skálázási problémája. Önnek még-senki-sem-használja problémája van, ami az ellenkező probléma. A több millió felhasználóra tervezett architektúrák lelassítják, amikor tizenegy felhasználója van. A híres cégek, amelyeket utánoz, először az egyszerű változatot építették meg, és később építették újra, a sikertől finanszírozva. Önnek is így kellene.

Hogy melyik adott keretrendszer „nyer" idén. A keretrendszerek egy divatciklusban emelkednek és buknak, amelynek szinte semmi köze ahhoz, hogy jól megépítik-e az Ön számlázó SaaS-ét. A főáramú, széles körben használt lehetőségek bármelyike elvégzi a munkát. A trend zaj; válasszon az unalmas, népszerű középmezőnyből, és lépjen tovább.

Miért nyer általában az „unalmas" technológia

A tapasztalt építők között él egy csendes bölcsesség, amelyet az újoncok kiábrándítónak találnak: egy új vállalkozás számára a legjobb technológia általában az unalmas, bizonyított, kissé divatjamúlt fajta. Nem azért, mert az új eszközök rosszak, hanem mert minden választás egy korlátozott újdonság-költségvetést költ el — azon ismeretlen, nem támogatott, meglepő dolgok számát, amelyekkel a kis csapata egyszerre megbirkózik.

Költse ezt a költségvetést arra, ami különlegessé teszi a vállalkozását — a tényleges termékre, arra a felismerésre, amellyel csak Ön rendelkezik. Ne költse egy olyan adatbázisra, amelyről senki sem hallott, csak hogy modernnek érezze magát. Egy unalmas, érett stack azt jelenti, hogy a problémákat már megoldották, a dokumentáció létezik, a toborzás könnyű, és az eszköz nem tűnik el jövőre, amikor egyetlen karbantartója elveszti az érdeklődését. Az unalmas lehetővé teszi, hogy minden lelkesedését oda tegye, ahol megtérül: az ügyfélbe.

Itt változtat a mesterséges intelligencia is kicsit a képen — és nem úgy, ahogy a hírverés sugallja. Az MI-kódolóasszisztensek drámaian jobbak az unalmas, népszerű technológiákban, mert egy évtizednyi nyilvános választ tanultak meg róluk. Válasszon főáramú stacket, és a csapata (és az eszközei) ingyen kapnak gyorsabb segítséget. Válasszon valami egzotikusat, és pontosan akkor van magára utalva, amikor a legkevésbé engedheti meg magának.

Döntési módszer, amelyet valóban használhat

Elég az elvekből. Íme egy konkrét módja annak, hogy döntésre jusson, akár maga választ, akár egy szabadúszónak ad briefet, akár azt értékeli, amit egy ügynökség javasol. Mindez nem kívánja meg, hogy kódot írjon — csak hogy a megfelelő dolgokat kérdezze, és mérlegelje a válaszokat.

1. 1
   A csapatból induljon ki, ne a technológiából

   Kérdezze meg: ki fogja ezt megépíteni és karbantartani a következő két évben? Bármi, amit már jól ismernek, az erős alapértelmezése. Stacket váltani egy divat hajszolásáért ritkán győzi le a folyékonyságot.
2. 2
   Alapértelmezésként a főáramút és bizonyítottat válassza

   Válasszon minden réteg népszerű, jól dokumentált középmezőnyéből. Ha nem talál gyorsan oktatóanyagokat, állásokat és nagy közösségeket egy eszközhöz, ezt kezelje figyelmeztetésként, ne előnyként.
3. 3
   A változásra optimalizáljon, ne a skálára

   Részesítse előnyben azt a választást, amely olcsóvá és gyorssá teszi a termék szerkesztését. A termékben ismételten tévedni fog — a stack feladata, hogy a tévedést túlélhetővé tegye.
4. 4
   Tartsa az architektúrát a lehető legegyszerűbbnek

   Egy adatbázis. Egy backend. Egy frontend. Semmi mikroszolgáltatás, semmi okos elosztott bármi, amíg egy valós, mért probléma rá nem kényszeríti. Az egyszerűség a cél, nem a kompromisszum.
5. 5
   Írja le, miért választotta

   Egy bekezdés: ki építi, mit választott, és minek kellene változnia ahhoz, hogy újragondolja. Ez a feljegyzés megóvja attól, hogy újra meg újra elővegye a döntést, valahányszor valaki elolvas egy heves véleményt.

Ha semmi mást nem követ, kövesse az egyes és négyes lépést. Építsen a meglévő emberekkel, a legegyszerűbb működő architektúrán. Ez a kombináció csendesen elkerüli azt a két kudarcmódot, amely a legtöbb első SaaS-terméket elsüllyeszti: senki, aki karban tudja tartani, és egy rendszer, amely túl bonyolult a saját méretéhez.

Kérdések, amelyeket bárkinek feltehet, aki stacket javasol

A legtöbb alapító nem egyedül választja a stacket — egy fejlesztő, egy ügynökség vagy egy CTO ismerős javasol egyet. Nem kell magának ellenőriznie a technológiát. Néhány kérdést kell feltennie, és figyelnie, hogyan válaszolnak. A magabiztos, közérthető válaszok jó jelek. A védekező szakzsargon nem.

• „Miért ez, és nem az unalmas, népszerű lehetőség?" — a jó válasz az Ön konkrét igényeiről szól, nem arról, mi a divatos.
• „Ha elütné egy busz, milyen könnyen vehetné át valaki más?" — a válasz elárulja, mennyire ritka és kockázatos a választás.
• „Mi ennek az architektúrának a legegyszerűbb változata, amely még működik?" — figyelje, az egyszerűség vagy a bonyolultság felé nyúlnak-e.
• „Mennyire lesz könnyű felvenni a következő fejlesztőt erre?" — a gyakori készségek egészséges piacot jelentenek; az egzotikusak függőséget.
• „Mi történik, ha három hónap múlva meg kell változtatnunk egy alapfunkciót?" — azt akarja hallani, hogy a változás olcsó, nem rettegett.

Gyakori csapdák, amelyek jó ötletnek tűnnek

Néhány minta olyan gyakran felbukkan, hogy érdemes megnevezni, mert mindegyik felelősségteljesnek érződik a pillanatban, és később drágán megfizetteti magát.

Olyan skálára építeni, amely nincs Önnek. A „csináljuk rendesen" késztetése arra viszi az alapítókat, hogy több millió felhasználóra tervezzenek, mielőtt tíz lenne. E jövőbiztosítás minden darabja olyan bonyolultság, amelyet most fizet meg, idővel és pénzzel, hogy megoldjon egy problémát, amely talán soha nem érkezik el. Építsen a következő száz felhasználóra. Tervezzen újra, amikor a növekedés szükségessé teszi — és hadd legyen ez egy örömteli probléma.

A legújabb dolog hajszolása. Egy múlt hónapban kiadott csillogó keretrendszernek nincs múltja, vékony a dokumentációja, és apró a közössége. Az éjszakáit az eszköz hibakeresésével fogja tölteni a termék építése helyett. Hagyja, hogy mások legyenek a korai alkalmazók; Önnek vállalkozást kell piacra vinnie.

A legolcsóbbnak kiszervezni, bármin, amit ő részesít előnyben. A legalacsonyabb ajánlat gyakran egy homályos stackkel érkezik, amelyet csak az az egy csapat ismer. Azon a napon, amikor elválnak útjaik, a terméke szigetté válik, amelyet senki más nem ér el. Olcsó az elején, pusztító később. Ragaszkodjon a főáramú, toborozható technológiához akkor is, amikor kiszervez — különösen, amikor kiszervez.

Mikor van valóban itt az ideje újragondolni a stacket

Mindez nem azt jelenti, hogy „soha ne változtasson". Azt jelenti, hogy valódi okokból változtasson, mértek, nem képzeltek alapján. Akkor fogja tudni, hogy valóban itt az ideje a stack fejlesztésének, amikor konkrét jelek bukkannak fel — nem amikor egy blogbejegyzés szorongóvá teszi.

Vegye észre a mintát: a valódi okok a tényleges vállalkozásában mért fájdalomról szólnak. A hamis okok divatról, összehasonlításról és nyugtalanságról. Amikor egy valódi jel mégis megjelenik, egyszerre egy darabot változtasson — ne az egész stacket egy hősies újraírásban, amely fél évre mindent megakaszt. Evolúció, nem forradalom.

Gyakori kérdések