Wybór stosu technologicznego dla pierwszego SaaS: szczery przewodnik dla założyciela

Zapytaj dziesięciu inżynierów, jakiego stosu technologicznego użyć do pierwszego SaaS, a dostaniesz piętnaście odpowiedzi, trzy z nich wygłoszone z pewnością wyznania wiary. Większość tych odpowiedzi jest słuszna — dla osoby, która je daje. Żadna nie dotyczy Państwa, Państwa zapasu gotówki ani klientów, których jeszcze nie pozyskaliście. Jeśli jako założyciel wpatrujecie się w tę decyzję i czujecie lekkie mdłości, oto rzecz, której nikt nie mówi na głos: stos liczy się znacznie mniej, niż Państwu wmówiono, a te nieliczne sposoby, w jakie jednak się liczy, to nie te, o które ludzie kłócą się w sieci.

Pomogłem sporej liczbie założycieli przejść od prezentacji do produktu, za który płacą prawdziwi ludzie. Prawie nikt z nich nie był techniczny. Prawie wszyscy przybywali, wchłonąwszy już przerażającą ilość folkloru o stosach — że potrzebują mikroserwisów, że jeden framework jest "martwy", że zły wybór ich pogrąży. I niemal za każdym razem stos okazywał się jedną z najmniej istotnych decyzji, jakie podjęli w danym roku. To, co zabijało projekty, to zakres, niejasna odpowiedzialność i piękne budowanie niewłaściwej rzeczy. Nigdy framework.

Oto więc przewodnik, który daję tym założycielom, zanim napiszemy choćby linijkę kodu. Nie powie Państwu, by użyć jednego konkretnego stosu, bo każdy, kto to obiecuje bez znajomości Państwa biznesu, coś sprzedaje. Zamiast tego da sposób myślenia — tak, by cokolwiek wybierzecie lub cokolwiek zaproponuje Państwa zespół, móc to sprawdzić jak dorosły, zamiast nerwowo przytakiwać.

Dlaczego ta decyzja wydaje się trudniejsza, niż jest

Pytanie o stos wydaje się ogromne, bo to pierwszy brzmiący nieodwracalnie wybór, którego dokonujecie, i jest owinięty w język, którym nie mówicie. Słowa takie jak Postgres, React, Kubernetes, serverless są rzucane tak, jakby wybór między nimi był jak wybór fundamentu budynku — pomyl się, a całość się zawali.

Ale oprogramowanie to nie budynek. Jest znacznie bliższe kuchni, którą można przebudowywać, wciąż gotując. Udane firmy nieustannie przepisują części swojego stosu; wersja produktu, która znajduje pierwszą setkę klientów, to prawie nigdy ta sama wersja, która obsługuje pierwszą setkę tysięcy. Celem Państwa pierwszego stosu nie jest przetrwanie na zawsze. Celem jest umożliwienie budowania, zmieniania i wypuszczania na tyle szybko, by dowiedzieć się, czy ktokolwiek tego w ogóle chce. To zupełnie inna — i znacznie niższa — poprzeczka niż "idealny na następną dekadę".

Gdy to przyjmiecie, presja spada o połowę. Nie próbujecie już przewidzieć przyszłości. Próbujecie postawić rozsądny, odwracalny zakład, który doprowadzi Was do działającego produktu i płacących użytkowników. A rozsądne zakłady to coś, co nietechniczny założyciel jak najbardziej potrafi ocenić.

Czym właściwie jest "stos", po ludzku

Zanim cokolwiek zdecydujecie, warto odczarować to słowo. Stos technologiczny to po prostu zbiór narzędzi używanych do budowania i uruchamiania Państwa oprogramowania. Można go ująć w czterech warstwach, a żadnej z nich nie trzeba rozumieć dogłębnie — wystarczy wiedzieć, że istnieją.

• Frontend — to, co użytkownicy widzą i klikają w przeglądarce lub aplikacji. To część, na podstawie której wszyscy Państwa oceniają.
• Backend — logika i reguły działające na serwerze: kto co może zrobić, co się dzieje, gdy to robi, jak przepływają pieniądze.
• Baza danych — gdzie naprawdę żyją Państwa informacje: użytkownicy, zamówienia, subskrypcje, wszystko, czego utrata byłaby druzgocąca.
• Infrastruktura — serwery i usługi, które utrzymują całość online, w kopii zapasowej i osiągalną o trzeciej nad ranem.

Gdy ktoś mówi "użyjemy nowoczesnego stosu JavaScript" albo "Rails na Postgresie", opisuje wybory w tych czterech warstwach. To wszystko. Każdy SaaS, od projektu dwóch osób po spółkę giełdową, to jakaś wersja tych czterech rzeczy ułożonych razem. Górnolotnie brzmiące diagramy architektury to dokładnie to, narysowane większą liczbą prostokątów.

Rzeczy, które naprawdę się liczą (i te, które nie)

Tu większość porad o stosie schodzi na manowce: optymalizuje pod kątem rzeczy, które nie wpływają na pierwsze dwa lata, a ignoruje te, które wpływają. Pozwolę sobie być szczery co do obu list.

Co naprawdę się liczy

Kto może to zbudować i utrzymywać. Pojedynczym najważniejszym czynnikiem nie jest technologia — to ludzie. Najlepszy stos dla Państwa to ten, w którym Państwa zespół (lub wynajęty partner) naprawdę potrafi biegle pracować już dziś. "Idealny" stos, który rozumie tylko jeden rzadki specjalista, jest gorszym wyborem niż nudny, który podejmie każdy kompetentny programista. Rekrutacja i ciągłość za każdym razem biją teoretyczną elegancję.

Jak szybko można zmieniać rzeczy. Na początku będziecie się stale mylić co do swojego produktu. Prawdziwym zadaniem stosu jest sprawić, by zmiana zdania była tania. Dojrzałe, dobrze udokumentowane narzędzia z dużymi społecznościami pozwalają działać szybko, bo odpowiedzi na Państwa problemy już istnieją. Narzędzia z najnowszej krawędzi czynią z Was osobę odkrywającą błędy.

Czy można na to rekrutować. Wybierzcie coś niszowego, a przywiążecie swoją przyszłość do tego, kto to zbudował. Wybierzcie coś powszechnego i nudnego, a zawsze znajdziecie kolejnego programistę, kolejną agencję, kolejną osobę, która to przejmie. Nudne jest zaletą, gdy zależy od tego Państwa biznes.

Co liczy się znacznie mniej, niż się mówi

Surowa wydajność i "skala". Nie macie problemu ze skalą. Macie problem nikt-jeszcze-tego-nie-używa, który jest problemem odwrotnym. Architektury zaprojektowane dla milionów użytkowników spowolnią Was, gdy macie ich jedenastu. Słynne firmy, które naśladujecie, najpierw zbudowały prostą wersję, a przebudowały później, finansując to sukcesem. Wy powinniście zrobić tak samo.

To, który konkretny framework "wygrywa" w tym roku. Frameworki rosną i upadają w cyklu mody, który ma niemal nic wspólnego z tym, czy dobrze zbudują Państwa SaaS do fakturowania. Każda z głównego nurtu, szeroko używanych opcji wykona zadanie. Trend to szum; wybierzcie z nudnego, popularnego środka i ruszajcie dalej.

Dlaczego "nudna" technologia zwykle wygrywa

Wśród doświadczonych twórców panuje cicha mądrość, którą nowicjusze uważają za rozczarowującą: najlepsza technologia dla nowego biznesu to zwykle ta nudna, sprawdzona, nieco niemodna. Nie dlatego, że nowe narzędzia są złe, lecz dlatego, że każdy wybór, jakiego dokonujecie, wydaje ograniczony budżet nowości — liczbę nieznanych, niewspieranych, zaskakujących rzeczy, którą Państwa mały zespół jest w stanie udźwignąć naraz.

Wydajcie ten budżet na to, co czyni Państwa biznes wyjątkowym — na sam produkt, na wgląd, który macie tylko Wy. Nie wydawajcie go na bazę danych, o której nikt nie słyszał, tylko po to, by poczuć się nowocześnie. Nudny, dojrzały stos oznacza, że problemy rozwiązano już wcześniej, dokumentacja istnieje, rekrutacja jest łatwa, a narzędzie nie zniknie za rok, gdy jego jedyny opiekun straci zainteresowanie. Nudne pozwala ulokować cały entuzjazm tam, gdzie się opłaca: w kliencie.

To także miejsce, gdzie AI nieco zmienia obraz — i nie w sposób, który sugeruje szum. Asystenci kodowania AI są radykalnie lepsi w nudnych, popularnych technologiach, bo trenowano ich na dekadzie publicznych odpowiedzi na ich temat. Wybierzcie stos z głównego nurtu, a Państwa zespół (i narzędzia) za darmo dostaną szybszą pomoc. Wybierzcie coś egzotycznego, a zostaniecie sami dokładnie wtedy, gdy najmniej Was na to stać.

Metoda decyzyjna, której naprawdę można użyć

Dość zasad. Oto konkretny sposób dojścia do decyzji, czy to wybierając samodzielnie, brefując freelancera, czy oceniając, co proponuje agencja. Nic z tego nie wymaga pisania kodu — jedynie zadawania właściwych rzeczy i ważenia odpowiedzi.

1. 1
   Zacznijcie od zespołu, nie od technologii

   Zapytajcie: kto buduje i utrzymuje to przez najbliższe dwa lata? Cokolwiek już dobrze znają, to Państwa silne ustawienie domyślne. Zmiana stosu w pogoni za trendem rzadko bije biegłość.
2. 2
   Domyślnie wybierajcie główny nurt i sprawdzone

   Wybierajcie z popularnego, dobrze udokumentowanego środka każdej warstwy. Jeśli nie potraficie szybko znaleźć dla narzędzia poradników, ofert pracy i dużych społeczności, potraktujcie to jako ostrzeżenie, nie zaletę.
3. 3
   Optymalizujcie pod zmianę, nie pod skalę

   Faworyzujcie wybór, który czyni edytowanie produktu tanim i szybkim. Będziecie się wielokrotnie mylić co do produktu — zadaniem stosu jest sprawić, by mylenie się dawało się przeżyć.
4. 4
   Trzymajcie architekturę tak prostą, jak to możliwe

   Jedna baza danych. Jeden backend. Jeden frontend. Bez mikroserwisów, bez sprytnego rozproszonego czegokolwiek, dopóki realny, zmierzony problem nie wymusi ruchu. Prostota to cel, nie kompromis.
5. 5
   Zapiszcie, dlaczego tak wybraliście

   Jeden akapit: kto to buduje, co wybraliście i co musiałoby się zmienić, byście do tego wrócili. Ta notatka oszczędza ponownego roztrząsania decyzji za każdym razem, gdy ktoś przeczyta gorącą opinię.

Jeśli nie pójdziecie za niczym innym, idźcie za krokiem pierwszym i czwartym. Budujcie z ludźmi, których macie, na najprostszej architekturze, która działa. To połączenie po cichu omija dwa tryby porażki, które topią większość pierwszych produktów SaaS: nikt, kto może to utrzymać, oraz system zbyt skomplikowany jak na swój rozmiar.

Pytania do tego, kto proponuje stos

Większość założycieli nie wybiera stosu samodzielnie — proponuje go programista, agencja lub zaprzyjaźniony CTO. Nie musicie weryfikować technologii sami. Musicie zadać kilka pytań i posłuchać, jak odpowiadają. Pewne odpowiedzi w prostym języku to dobry znak. Defensywny żargon nie.

• "Dlaczego to, a nie nudna popularna opcja?" — dobra odpowiedź dotyczy Państwa konkretnych potrzeb, a nie tego, co modne.
• "Gdyby potrącił Pana autobus, jak łatwo ktoś inny mógłby to przejąć?" — odpowiedź ujawnia, jak rzadki i ryzykowny jest wybór.
• "Jaka jest najprostsza wersja tej architektury, która wciąż działa?" — patrzcie, czy sięgają po prostotę, czy po złożoność.
• "Jak łatwo będzie zrekrutować kolejnego programistę do tego?" — powszechne umiejętności oznaczają zdrowy rynek; egzotyczne oznaczają zależność.
• "Co się stanie, gdy za trzy miesiące będziemy musieli zmienić kluczową funkcję?" — chcecie usłyszeć, że zmiana jest tania, a nie budząca lęk.

Częste pułapki, które wyglądają jak dobre pomysły

Kilka wzorców pojawia się tak często, że warto je nazwać, bo każdy wydaje się w danej chwili odpowiedzialny, a później sporo kosztuje.

Budowanie pod skalę, której nie macie. Pragnienie, by "zrobić to porządnie", skłania założycieli do projektowania pod miliony użytkowników, zanim mają dziesięciu. Każdy kawałek tego zabezpieczania na przyszłość to złożoność, za którą płacicie teraz, czasem i pieniędzmi, by rozwiązać problem, który może nigdy nie nadejdzie. Budujcie pod następną setkę użytkowników. Przeprojektujcie, gdy wzrost to wymusi — i niech to będzie miły problem.

Pogoń za najnowszym. Błyszczący framework wydany w zeszłym miesiącu nie ma historii, ma cienką dokumentację i maleńką społeczność. Spędzicie noce, debugując narzędzie zamiast budować produkt. Niech to inni będą wczesnymi adoptującymi; Wy macie biznes do wypuszczenia.

Zlecanie temu, kto najtańszy, na czymkolwiek woli. Najniższa oferta często przychodzi z niszowym stosem, który zna tylko ten jeden zespół. W dniu, w którym się rozstaniecie, Państwa produkt staje się wyspą, do której nikt inny nie dotrze. Tanio z przodu, rujnująco później. Nalegajcie na technologię z głównego nurtu, na którą da się rekrutować, nawet gdy zlecacie na zewnątrz — zwłaszcza gdy zlecacie na zewnątrz.

Kiedy naprawdę nadchodzi czas, by zrewidować stos

Nic z tego nie oznacza "nigdy nie zmieniać". Oznacza zmieniać z realnych powodów, zmierzonych, nie wyobrażonych. Poznacie, że naprawdę nadszedł czas, by rozwinąć stos, gdy pojawią się konkretne sygnały — a nie gdy wpis na blogu przyprawi Was o lęk.

Zauważcie wzorzec: realne powody dotyczą zmierzonego bólu w Państwa faktycznym biznesie. Fałszywe powody dotyczą mody, porównań i niepokoju. Gdy realny sygnał już się pojawi, zmieniacie po jednym kawałku — a nie cały stos w heroicznym przepisaniu, które zatrzyma wszystko na pół roku. Ewolucja, nie rewolucja.

Częste pytania