Избор на технологичен стек за първия ви SaaS: честно ръководство за основатели
Повечето спорове за стека са религиозни войни между инженери, които никога няма да ползват продукта ви. Това е по-спокойната версия: как нетехнически основател избира стек, който извежда SaaS до реални плащащи клиенти, без да заложи компанията на поредната мода.

Попитайте десет инженери кой стек да ползвате за първия си SaaS и ще получите петнайсет отговора, три от които изречени с религиозна увереност. Повечето от тези отговори са верни — за човека, който ги дава. Никой от тях не е за вас, за парите, които ви остават, или за клиентите, които още не сте подписали. Ако сте основател, който се взира в това решение и му е леко зле, ето какво никой не казва на глас: стекът има далеч по-малко значение, отколкото са ви внушили, а малкото случаи, в които наистина има значение, не са онези, за които спорят в интернет.
Помогнал съм на доста основатели да минат от презентация до продукт, за който реални хора плащат. Почти никой от тях не беше технически. Почти всички пристигнаха, попили плашещо количество фолклор за стека — че им трябват микросървиси, че една рамка е „мъртва“, че грешен избор ще ги обрече. И почти всеки път стекът се оказваше едно от най-маловажните решения, които взеха онази година. Това, което убиваше проектите, беше обхватът, неясната отговорност и красивото изграждане на грешното нещо. Никога рамката.
Затова това е ръководството, което давам на тези основатели, преди да напишем и ред код. То няма да ви каже да ползвате един конкретен стек, защото всеки, който обещава това, без да познава бизнеса ви, продава нещо. Вместо това ще ви даде начин да мислите — така че каквото и да изберете или каквото и да предложи екипът ви, да можете да го проверите трезво като възрастен, вместо нервно да кимате в съгласие.
Защо това решение изглежда по-трудно, отколкото е
Въпросът за стека изглежда огромен, защото е първият на пръв поглед необратим избор, който правите, и е увит в език, който не говорите. Думи като Postgres, React, Kubernetes, serverless се подхвърлят така, сякаш изборът между тях е като избор на основите на сграда — сгрешите ли, всичко се срутва.
Но софтуерът не е сграда. Той е много по-близо до кухня, която можете да преобзаведете, докато готвите. Успешните компании постоянно пренаписват части от стека си; версията на продукт, която намира първите си сто клиенти, почти никога не е версията, която обслужва първите сто хиляди. Целта на първия ви стек не е да издържи вечно. Тя е да ви позволи да изграждате, променяте и пускате достатъчно бързо, за да разберете дали изобщо някой иска това. Това е съвсем различна — и много по-ниска — летва от „идеален за следващото десетилетие“.
“Първият ви стек не трябва да е този, на който ще мащабирате. Той трябва да е този, който ви позволява да разберете дали мащабирането изобщо е проблем, който си заслужава да имате.”
Щом приемете това, напрежението спада наполовина. Вече не се опитвате да предскажете бъдещето. Опитвате се да направите разумен, обратим залог, който ви води до работещ продукт и плащащи потребители. А разумните залози са нещо, което нетехнически основател напълно може да прецени.
Какво всъщност е „стек“, казано просто
Преди да решавате каквото и да било, помага да демистифицираме думата. Технологичният стек е просто наборът от инструменти, с които се изгражда и работи софтуерът ви. Можете да го мислите на четири слоя и не е нужно да разбирате нито един от тях задълбочено — нужно е само да знаете, че съществуват.
- Фронтендът — онова, което потребителите виждат и натискат в браузъра или приложението си. Това е частта, по която всеки ви съди.
- Бекендът — логиката и правилата, които работят на сървър: кой какво може да прави, какво се случва, когато го направи, как се движат парите.
- Базата данни — където реално живее информацията ви: потребители, поръчки, абонаменти, всичко, чиято загуба би ви съсипала.
- Инфраструктурата — сървърите и услугите, които държат всичко по-горе онлайн, архивирано и достъпно в 3 сутринта.
Когато някой каже „ще ползваме модерен JavaScript стек“ или „Rails върху Postgres“, той описва избори в тези четири слоя. Това е всичко. Всеки SaaS, от двучленен страничен проект до публична компания, е някаква версия на тези четири неща, наредени едно върху друго. Внушителните диаграми на архитектурата са просто това, нарисувано с повече кутийки.

Нещата, които наистина имат значение (и тези, които нямат)
Тук повечето съвети за стека грешат: оптимизират за неща, които не влияят на първите ви две години, и пренебрегват тези, които влияят. Нека бъда прям и за двата списъка.
Какво наистина има значение
Кой може да го изгражда и поддържа. Най-големият фактор не е технологията — а хората. Най-добрият стек за вас е този, в който екипът ви (или партньорът, когото наемете) реално може да работи свободно днес. „Перфектен“ стек, който разбира само един рядък специалист, е по-лош избор от скучен, който всеки компетентен разработчик може да подхване. Наемането и приемствеността бият теоретичната елегантност всеки път.
Колко бързо можете да променяте нещата. В началото постоянно ще грешите за продукта си. Истинската работа на стека е да направи смяната на мнението евтина. Зрелите, добре документирани инструменти с големи общности ви позволяват да се движите бързо, защото отговорите на проблемите ви вече съществуват. Свръхновите инструменти ви правят човекът, който открива бъговете.
Дали можете да наемате за него. Изберете нещо неясно и обвързвате бъдещето си с този, който го е изградил. Изберете нещо разпространено и скучно и винаги ще намерите следващия разработчик, следващата агенция, следващия човек, който да поеме. Скучното е предимство, когато бизнесът ви зависи от него.
Какво има далеч по-малко значение, отколкото казват
Чистата производителност и „мащабът“. Нямате проблем с мащаба. Имате проблем, че никой още не го ползва, което е обратният проблем. Архитектури, проектирани за милиони потребители, ще ви забавят, когато имате единайсет. Прочутите компании, които имитирате, първо изградиха простата версия и я преизградиха по-късно, финансирани от успеха. Така трябва и вие.
Коя точно рамка „печели“ тази година. Рамките се издигат и падат в моден цикъл, който почти няма нищо общо с това дали ще изградят добре вашия SaaS за фактуриране. Всяка от масовите, широко използвани опции ще свърши работа. Тенденцията е шум; изберете от скучната, популярна среда и продължете нататък.
Защо „скучната“ технология обикновено побеждава
Сред опитните строители има тиха мъдрост, която новодошлите намират за разочароваща: най-добрата технология за нов бизнес обикновено е скучната, доказана, леко немодна. Не защото новите инструменти са лоши, а защото всеки избор харчи от ограничен бюджет от новост — броя непознати, неподдържани, изненадващи неща, които малкият ви екип може да поеме наведнъж.
Похарчете този бюджет за нещото, което прави бизнеса ви специален — самия продукт, прозрението, което имате само вие. Не го харчете за база данни, за която никой не е чувал, само за да се чувствате модерни. Скучен, зрял стек означава, че проблемите вече са решени, документацията съществува, наемането е лесно и инструментът няма да изчезне догодина, когато единственият му поддръжник изгуби интерес. Скучното ви позволява да насочите цялото си вълнение там, където то се отплаща: към клиента.

Тук ИИ също леко променя картината — и не по начина, който подсказва хайпът. ИИ асистентите за код са драматично по-добри при скучните, популярни технологии, защото са обучени върху десетилетие публични отговори за тях. Изберете масов стек и екипът ви (и инструментите ви) получават по-бърза помощ безплатно. Изберете нещо екзотично и оставате сами точно тогава, когато най-малко можете да си го позволите.
Метод за решаване, който наистина можете да ползвате
Достатъчно принципи. Ето конкретен начин да стигнете до решение, независимо дали избирате сами, инструктирате фрийлансър или оценявате какво предлага агенция. Нищо от това не изисква да пишете код — само да питате правилните неща и да претеглите отговорите.
- 1Тръгнете от екипа, не от технологиятаПопитайте: кой ще изгражда и поддържа това през следващите две години? Каквото вече знаят добре, е силната ви настройка по подразбиране. Смяната на стека в гонене на мода рядко бие свободното владеене.
- 2По подразбиране — масово и доказаноИзберете от популярната, добре документирана среда на всеки слой. Ако не можете бързо да намерите уроци, обяви за работа и големи общности за даден инструмент, приемете това като предупреждение, не като предимство.
- 3Оптимизирайте за промяна, не за мащабПредпочетете избора, който прави редактирането на продукта евтино и бързо. Многократно ще грешите за продукта — работата на стека е да направи грешенето преживяемо.
- 4Дръжте архитектурата възможно най-простаЕдна база данни. Един бекенд. Един фронтенд. Без микросървиси, без хитро разпределено каквото и да било, докато реален, измерен проблем не ви принуди. Простотата е целта, не компромисът.
- 5Запишете защо сте го избралиЕдин абзац: кой го изгражда, какво сте избрали и какво би трябвало да се промени, за да го преразгледате. Тази бележка ви спасява от това да преразглеждате решението всеки път, щом някой прочете поредното категорично мнение.
Ако не следвате нищо друго, следвайте стъпки едно и четири. Изграждайте с хората, които имате, върху най-простата архитектура, която работи. Тази комбинация тихо избягва двата провала, които потапят повечето първи SaaS продукти: никой, който може да го поддържа, и система, прекалено сложна за размера си.
Въпроси към всеки, който предлага стек
Повечето основатели не избират стека сами — разработчик, агенция или приятел CTO предлага. Не е нужно сами да проверявате технологията. Нужно е да зададете шепа въпроси и да слушате как отговарят. Уверените отговори на прост език са добър знак. Защитният жаргон — не.
- „Защо точно това, а не скучната популярна опция?“ — добрият отговор е за вашите конкретни нужди, не за това какво е модерно.
- „Ако те блъсне автобус, колко лесно някой друг ще поеме това?“ — отговорът разкрива колко рядък и рисков е изборът.
- „Коя е най-простата версия на тази архитектура, която още работи?“ — гледайте дали посягат към простота или към сложност.
- „Колко лесно ще е да наемем следващия разработчик за това?“ — масовите умения значат здрав пазар; екзотичните — зависимост.
- „Какво става, когато след три месеца трябва да сменим основна функция?“ — искате да чуете, че промяната е евтина, не страховита.

Често срещани капани, които изглеждат като добри идеи
Няколко модела се срещат толкова често, че си заслужава да бъдат назовани, защото всеки от тях изглежда отговорен в момента и ви струва скъпо по-късно.
Изграждане за мащаб, който нямате. Подтикът да „го направим както трябва“ кара основателите да проектират за милиони потребители, преди да имат десет. Всяка частица от това подготвяне за бъдещето е сложност, която плащате сега, във време и пари, за да решите проблем, който може и да не дойде. Изграждайте за следващите сто потребители. Преархитектурирайте, когато растежът го наложи — и нека това е щастлив проблем.
Гонене на най-новото. Бляскава рамка, излязла миналия месец, няма история, има оскъдна документация и мъничка общност. Ще прекарвате нощите си в дебъгване на инструмента вместо в изграждане на продукта. Оставете други да са ранните последователи; вие имате бизнес за пускане.
Възлагане на най-евтиния, на каквото той предпочита. Най-ниската оферта често идва с неясен стек, който знае само онзи екип. В деня, в който се разделите, продуктът ви става остров, до който никой друг не може да стигне. Евтино в началото, гибелно по-късно. Настоявайте за масова, наемаема технология, дори когато възлагате — особено когато възлагате.
“Правилният стек е този, който непознат може да подхване и да продължи. Ако само човекът, който го е изградил, го разбира, не притежавате продукт — притежавате зависимост.”
Кога наистина е време да преразгледате стека си
Нищо от това не значи „никога не променяй“. Значи променяй по реални причини, измерени, не въобразени. Ще разберете, че наистина е време да развиете стека си, когато се появят конкретни сигнали — не когато някоя статия в блог ви разтревожи.
| Сигнал | Реална причина за промяна? | Какво да направите |
|---|---|---|
| Приложението е измеримо бавно за реални потребители | Да | Първо измерете, после поправете конкретното тясно място |
| Добавянето на функции става все по-бавно | Да | Опростете или рефакторирайте болезнената част |
| Не можете да наемете никого, който го знае | Да | Планирайте съзнателна миграция към масови инструменти |
| Конкурент ползва по-моден стек | Не | Игнорирайте — стекът им не е тяхното предимство |
| Излезе нова рамка и изглежда яко | Не | Запазете я в отметките, продължете да пускате |
| На инженер просто му е скучно | Не | Адресирайте духа, не архитектурата |
Забележете модела: реалните причини са за измерена болка в реалния ви бизнес. Фалшивите причини са за мода, сравнение и неспокойствие. Когато наистина се появи реален сигнал, променяте по едно парче — а не целия стек в героично пренаписване, което спира всичко за шест месеца. Еволюция, не революция.
Искате второ мнение, преди да се обвържете?
Изборът на стек — или трезвата проверка на този, който някой е предложил — е проблем от един разговор много по-често, отколкото основателите очакват. С удоволствие ще погледнем идеята ви и ще ви кажем честно какво си заслужава да се изгради, как и какво да остане просто.
Вижте как изграждаме софтуерЧесто задавани въпроси
Има ли един най-добър технологичен стек за SaaS стартъп?
Трябва ли да ползвам най-новата, най-модерна рамка?
Трябват ли ми микросървиси или „мащабируема“ архитектура от първия ден?
Как да преценя стек, ако не съм технически?
Ами ако избера грешно — заклещен ли съм завинаги?

Have a nice day е софтуерно студио, което помага на малките и средните предприятия да се дигитализират — автоматизация, изкуствен интелект и софтуер по поръчка, който работи в ежедневната дейност, а не само на слайдове.