Cum alegeți un stack tehnologic pentru primul vostru SaaS: un ghid onest pentru fondatori

Întrebați zece ingineri ce stack tehnologic ar trebui să folosiți pentru primul vostru SaaS și veți primi cincisprezece răspunsuri, trei dintre ele rostite cu certitudinea unei religii. Cele mai multe dintre aceste răspunsuri sunt corecte — pentru cel care le dă. Niciunul nu este despre dumneavoastră, despre cât timp vă mai ajung banii sau despre clienții pe care încă nu i-ați semnat. Dacă sunteți un fondator care privește această decizie simțindu-vă ușor rău, iată ce nu spune nimeni cu voce tare: stack-ul contează mult mai puțin decât ați fost făcut să credeți, iar cele câteva moduri în care contează nu sunt cele despre care se ceartă lumea online.

Am ajutat un număr bunicel de fondatori la prima experiență să treacă de la o prezentare la un produs pentru care oameni reali plătesc. Aproape niciunul nu era tehnic. Aproape toți au sosit după ce absorbiseră deja o cantitate înspăimântătoare de folclor despre stack-uri — că aveau nevoie de microservicii, că un anumit framework era „mort", că alegerea greșită i-ar fi distrus. Și aproape de fiecare dată, stack-ul s-a dovedit a fi una dintre cele mai puțin importante decizii pe care le-au luat în acel an. Ce a ucis proiectele a fost amploarea, responsabilitatea neclară și construirea lucrului greșit în mod frumos. Niciodată framework-ul.

Așadar acesta este ghidul pe care îl ofer acelor fondatori înainte de a scrie o singură linie de cod. Nu vă va spune să folosiți un stack anume, fiindcă oricine vă promite asta fără să vă cunoască afacerea vă vinde ceva. În schimb, vă va oferi un mod de a gândi — astfel încât, orice ați alege sau orice v-ar propune echipa, să puteți verifica acel lucru ca un om matur, în loc să dați din cap nervos.

De ce această decizie pare mai grea decât este

Întrebarea despre stack pare enormă fiindcă este prima alegere care sună ireversibilă pe care o faceți și este învelită într-o limbă pe care nu o vorbiți. Cuvinte precum Postgres, React, Kubernetes, serverless sunt aruncate de parcă a alege între ele ar fi ca a alege fundația unei clădiri — o greșeală și totul se prăbușește.

Dar software-ul nu este o clădire. Seamănă mult mai mult cu o bucătărie pe care o puteți reamenaja în timp ce încă gătiți. Companiile de succes rescriu părți din stack-ul lor constant; versiunea unui produs care își găsește primii o sută de clienți nu este aproape niciodată versiunea care servește primii o sută de mii. Scopul primului vostru stack nu este să dureze pentru totdeauna. Este să vă lase să construiți, să schimbați și să lansați suficient de repede încât să aflați dacă cineva își dorește asta. Acesta este un prag complet diferit — și mult mai jos — decât „perfect pentru următorul deceniu".

Odată ce acceptați asta, presiunea scade la jumătate. Nu mai încercați să preziceți viitorul. Încercați să faceți un pariu rezonabil și reversibil care vă duce la un produs funcțional și la utilizatori plătitori. Iar pariurile rezonabile sunt ceva ce un fondator netehnic poate evalua cu siguranță.

Ce este de fapt un „stack", pe înțelesul tuturor

Înainte de a decide ceva, ajută să demistificăm cuvântul. Un stack tehnologic este pur și simplu colecția de instrumente folosite pentru a construi și rula software-ul vostru. Vă puteți gândi la el în patru straturi și nu trebuie să înțelegeți niciunul în profunzime — e suficient să știți că există.

• Frontend-ul — ceea ce văd și pe ce dau clic utilizatorii în browserul sau aplicația lor. Aceasta este partea după care vă judecă toată lumea.
• Backend-ul — logica și regulile care rulează pe un server: cine ce poate face, ce se întâmplă când o face, cum circulă banii.
• Baza de date — unde trăiesc de fapt informațiile voastre: utilizatori, comenzi, abonamente, tot ce v-ar devasta să pierdeți.
• Infrastructura — serverele și serviciile care țin toate cele de mai sus online, salvate și accesibile la 3 dimineața.

Când cineva spune „vom folosi un stack JavaScript modern" sau „Rails pe Postgres", descrie alegeri de-a lungul acestor patru straturi. Atât. Fiecare SaaS, de la un proiect secundar a doi oameni până la o companie publică, este o versiune a acestor patru lucruri stivuite împreună. Diagramele de arhitectură care sună grandios sunt doar atât, desenate cu mai multe căsuțe.

Lucrurile care contează cu adevărat (și cele care nu)

Aici greșesc cele mai multe sfaturi despre stack-uri: optimizează pentru lucruri care nu vă afectează primii doi ani și ignoră lucrurile care o fac. Permiteți-mi să fiu direct cu privire la ambele liste.

Ce contează cu adevărat

Cine îl poate construi și întreține. Cel mai important factor nu este tehnologia — sunt oamenii. Cel mai bun stack pentru voi este cel în care echipa voastră (sau partenerul pe care îl angajați) poate lucra de fapt, fluent, astăzi. Un stack „perfect" pe care îl înțelege doar un specialist rar este o alegere mai proastă decât unul plictisitor pe care orice dezvoltator competent îl poate prelua. Angajarea și continuitatea bat eleganța teoretică de fiecare dată.

Cât de repede puteți schimba lucrurile. La început vă veți înșela în privința produsului în mod constant. Adevărata sarcină a stack-ului este să facă schimbarea de opinie ieftină. Instrumentele mature, bine documentate, cu comunități mari vă lasă să vă mișcați rapid fiindcă răspunsurile la problemele voastre există deja. Instrumentele de ultimă oră vă transformă în persoana care descoperă bug-urile.

Dacă puteți angaja pentru el. Alegeți ceva obscur și vă legați viitorul de cel care l-a construit. Alegeți ceva comun și plictisitor și veți putea găsi mereu următorul dezvoltator, următoarea agenție, următoarea persoană care să preia. Plictisitorul este o calitate când afacerea voastră depinde de el.

Ce contează mult mai puțin decât se spune

Performanța brută și „scalarea". Nu aveți o problemă de scalare. Aveți o problemă de nimeni-nu-l-folosește-încă, care este problema opusă. Arhitecturile concepute pentru milioane de utilizatori vă vor încetini când aveți unsprezece. Companiile celebre pe care le imitați au construit mai întâi versiunea simplă și au reconstruit mai târziu, finanțate de succes. La fel ar trebui să faceți și voi.

Care framework anume „câștigă" anul acesta. Framework-urile cresc și scad pe un ciclu al modei care nu are aproape nimic de-a face cu faptul dacă vă vor construi bine SaaS-ul de facturare. Oricare dintre opțiunile mainstream, larg folosite, va face treaba. Trendul este zgomot; alegeți din mijlocul plictisitor și popular și mergeți mai departe.

De ce tehnologia „plictisitoare" câștigă de obicei

Există o înțelepciune tăcută printre constructorii experimentați pe care nou-veniții o găsesc dezamăgitoare: cea mai bună tehnologie pentru o afacere nouă este de obicei cea plictisitoare, dovedită, ușor demodată. Nu fiindcă instrumentele noi sunt rele, ci fiindcă fiecare alegere pe care o faceți cheltuie un buget limitat de noutate — numărul de lucruri nefamiliare, nesusținute, surprinzătoare pe care echipa voastră mică le poate gestiona deodată.

Cheltuiți acel buget pe lucrul care vă face afacerea specială — produsul propriu-zis, perspectiva pe care doar voi o aveți. Nu îl cheltuiți pe o bază de date de care nu a auzit nimeni doar ca să vă simțiți moderni. Un stack plictisitor și matur înseamnă că problemele au mai fost rezolvate, că documentația există, că angajarea e ușoară și că instrumentul nu va dispărea anul viitor când singurul lui întreținător își pierde interesul. Plictisitorul vă lasă să puneți tot entuziasmul acolo unde se plătește: în client.

Aici intervine și inteligența artificială, schimbând puțin tabloul — și nu așa cum sugerează agitația. Asistenții de programare cu IA sunt dramatic mai buni la tehnologiile plictisitoare și populare, fiindcă au fost antrenați pe un deceniu de răspunsuri publice despre ele. Alegeți un stack mainstream și echipa voastră (și instrumentele voastre) primesc ajutor mai rapid, gratis. Alegeți ceva exotic și sunteți pe cont propriu exact când vă puteți permite cel mai puțin.

O metodă de decizie pe care chiar o puteți folosi

Destule principii. Iată un mod concret de a ajunge la o decizie, fie că alegeți singuri, fie că instruiți un freelancer, fie că evaluați ce propune o agenție. Nimic din toate astea nu vă cere să scrieți cod — doar să întrebați lucrurile potrivite și să cântăriți răspunsurile.

1. 1
   Porniți de la echipă, nu de la tehnologie

   Întrebați: cine va construi și întreține asta în următorii doi ani? Orice știu ei deja bine este alegerea voastră implicită puternică. Schimbarea stack-ului pentru a urmări o modă rareori bate fluența.
2. 2
   Implicit, alegeți mainstream și dovedit

   Alegeți din mijlocul popular, bine documentat, al fiecărui strat. Dacă nu găsiți repede tutoriale, joburi și comunități mari pentru un instrument, tratați asta ca pe un avertisment, nu ca pe o calitate.
3. 3
   Optimizați pentru schimbare, nu pentru scalare

   Favorizați alegerea care face editarea produsului ieftină și rapidă. Vă veți înșela în privința produsului în mod repetat — sarcina stack-ului este să facă greșeala suportabilă.
4. 4
   Păstrați arhitectura cât de simplă poate fi

   O bază de date. Un backend. Un frontend. Fără microservicii, fără nimic distribuit ingenios, până când o problemă reală, măsurată, vă forțează mâna. Simplitatea este scopul, nu compromisul.
5. 5
   Scrieți de ce ați ales-o

   Un paragraf: cine o construiește, ce ați ales și ce ar trebui să se schimbe ca să reveniți asupra deciziei. Această notă vă scapă de a relua dezbaterea de fiecare dată când cineva citește o opinie aprinsă.

Dacă nu urmați nimic altceva, urmați pașii unu și patru. Construiți cu oamenii pe care îi aveți, pe cea mai simplă arhitectură care funcționează. Această combinație evită discret cele două moduri de eșec care scufundă cele mai multe prime produse SaaS: nimeni care să-l poată întreține și un sistem prea complicat pentru propria dimensiune.

Întrebări de pus oricui propune un stack

Cei mai mulți fondatori nu aleg stack-ul singuri — un dezvoltator, o agenție sau un prieten CTO propune unul. Nu trebuie să verificați tehnologia voi înșivă. Trebuie să puneți câteva întrebări și să ascultați cum răspund. Răspunsurile sigure, în limbaj simplu, sunt un semn bun. Jargonul defensiv nu este.

• „De ce asta și nu opțiunea plictisitoare și populară?" — un răspuns bun e despre nevoile voastre specifice, nu despre ce e la modă.
• „Dacă v-ar lovi un autobuz, cât de ușor ar putea altcineva să preia asta?" — răspunsul dezvăluie cât de rară și riscantă e alegerea.
• „Care e cea mai simplă versiune a acestei arhitecturi care încă funcționează?" — observați dacă tind spre simplitate sau spre complexitate.
• „Cât de ușor va fi să angajăm următorul dezvoltator pentru asta?" — competențele comune înseamnă o piață sănătoasă; cele exotice înseamnă dependență.
• „Ce se întâmplă când trebuie să schimbăm o funcție de bază peste trei luni?" — vreți să auziți că schimbarea e ieftină, nu temută.

Capcane comune care par idei bune

Câteva tipare apar atât de des încât merită numite, fiindcă fiecare pare responsabil în acel moment și vă costă scump mai târziu.

Să construiți pentru o scalare pe care nu o aveți. Pornirea de a „face cum trebuie" îi duce pe fondatori să proiecteze pentru milioane de utilizatori înainte de a avea zece. Fiecare bucățică din această pregătire pentru viitor este complexitate pe care o plătiți acum, în timp și bani, pentru a rezolva o problemă care s-ar putea să nu apară niciodată. Construiți pentru următorii o sută de utilizatori. Reproiectați când creșterea o face necesară — și lăsați să fie o problemă plăcută.

Să urmăriți cel mai nou lucru. Un framework strălucitor lansat luna trecută nu are niciun istoric, documentație subțire și o comunitate minusculă. Vă veți petrece nopțile depanând instrumentul în loc să vă construiți produsul. Lăsați-i pe alții să fie adoptatorii timpurii; voi aveți o afacere de lansat.

Să externalizați către cine e cel mai ieftin, pe orice preferă el. Cea mai mică ofertă vine adesea cu un stack obscur pe care doar acea echipă îl știe. În ziua în care vă despărțiți, produsul vostru devine o insulă la care nimeni altcineva nu poate ajunge. Ieftin la început, ruinător mai târziu. Insistați pe tehnologie mainstream, pentru care se poate angaja, chiar și când externalizați — mai ales când externalizați.

Când chiar e momentul să vă reconsiderați stack-ul

Nimic din toate astea nu înseamnă „nu schimbați niciodată". Înseamnă să schimbați din motive reale, măsurate, nu imaginate. Veți ști că e cu adevărat momentul să vă faceți stack-ul să evolueze când apar semnale concrete — nu când un articol de blog vă face anxioși.

Observați tiparul: motivele reale sunt despre durere măsurată în afacerea voastră concretă. Motivele false sunt despre modă, comparație și neliniște. Când apare un semnal real, schimbați o piesă pe rând — nu întregul stack într-o rescriere eroică care blochează totul timp de șase luni. Evoluție, nu revoluție.

Întrebări frecvente