Ръководство

Избор на технологичен стек за първия ви SaaS: честно ръководство за основатели

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

Have a nice dayHave a nice day13 мин. четене
Избор на технологичен стек за първия ви SaaS: честно ръководство за основатели

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

Помогнал съм на доста основатели да минат от презентация до продукт, за който реални хора плащат. Почти никой от тях не беше технически. Почти всички пристигнаха, попили плашещо количество фолклор за стека — че им трябват микросървиси, че една рамка е „мъртва“, че грешен избор ще ги обрече. И почти всеки път стекът се оказваше едно от най-маловажните решения, които взеха онази година. Това, което убиваше проектите, беше обхватът, неясната отговорност и красивото изграждане на грешното нещо. Никога рамката.

Затова това е ръководството, което давам на тези основатели, преди да напишем и ред код. То няма да ви каже да ползвате един конкретен стек, защото всеки, който обещава това, без да познава бизнеса ви, продава нещо. Вместо това ще ви даде начин да мислите — така че каквото и да изберете или каквото и да предложи екипът ви, да можете да го проверите трезво като възрастен, вместо нервно да кимате в съгласие.

Защо това решение изглежда по-трудно, отколкото е

Въпросът за стека изглежда огромен, защото е първият на пръв поглед необратим избор, който правите, и е увит в език, който не говорите. Думи като Postgres, React, Kubernetes, serverless се подхвърлят така, сякаш изборът между тях е като избор на основите на сграда — сгрешите ли, всичко се срутва.

Но софтуерът не е сграда. Той е много по-близо до кухня, която можете да преобзаведете, докато готвите. Успешните компании постоянно пренаписват части от стека си; версията на продукт, която намира първите си сто клиенти, почти никога не е версията, която обслужва първите сто хиляди. Целта на първия ви стек не е да издържи вечно. Тя е да ви позволи да изграждате, променяте и пускате достатъчно бързо, за да разберете дали изобщо някой иска това. Това е съвсем различна — и много по-ниска — летва от „идеален за следващото десетилетие“.

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

Щом приемете това, напрежението спада наполовина. Вече не се опитвате да предскажете бъдещето. Опитвате се да направите разумен, обратим залог, който ви води до работещ продукт и плащащи потребители. А разумните залози са нещо, което нетехнически основател напълно може да прецени.

Какво всъщност е „стек“, казано просто

Преди да решавате каквото и да било, помага да демистифицираме думата. Технологичният стек е просто наборът от инструменти, с които се изгражда и работи софтуерът ви. Можете да го мислите на четири слоя и не е нужно да разбирате нито един от тях задълбочено — нужно е само да знаете, че съществуват.

  • Фронтендът — онова, което потребителите виждат и натискат в браузъра или приложението си. Това е частта, по която всеки ви съди.
  • Бекендът — логиката и правилата, които работят на сървър: кой какво може да прави, какво се случва, когато го направи, как се движат парите.
  • Базата данни — където реално живее информацията ви: потребители, поръчки, абонаменти, всичко, чиято загуба би ви съсипала.
  • Инфраструктурата — сървърите и услугите, които държат всичко по-горе онлайн, архивирано и достъпно в 3 сутринта.

Когато някой каже „ще ползваме модерен JavaScript стек“ или „Rails върху Postgres“, той описва избори в тези четири слоя. Това е всичко. Всеки SaaS, от двучленен страничен проект до публична компания, е някаква версия на тези четири неща, наредени едно върху друго. Внушителните диаграми на архитектурата са просто това, нарисувано с повече кутийки.

Чиста, приятелска четирислойна диаграма на софтуерен стек — фронтенд, бекенд, база данни, инфраструктура — нарисувана като подредени хоризонтални плочи с малки иконки, в спокоен редакционен плосък стил на светъл фон
Всеки SaaS е някаква версия на тези четири слоя. Споровете в интернет са най-вече коя марка плоча да се ползва.

Нещата, които наистина имат значение (и тези, които нямат)

Тук повечето съвети за стека грешат: оптимизират за неща, които не влияят на първите ви две години, и пренебрегват тези, които влияят. Нека бъда прям и за двата списъка.

Какво наистина има значение

Кой може да го изгражда и поддържа. Най-големият фактор не е технологията — а хората. Най-добрият стек за вас е този, в който екипът ви (или партньорът, когото наемете) реално може да работи свободно днес. „Перфектен“ стек, който разбира само един рядък специалист, е по-лош избор от скучен, който всеки компетентен разработчик може да подхване. Наемането и приемствеността бият теоретичната елегантност всеки път.

Колко бързо можете да променяте нещата. В началото постоянно ще грешите за продукта си. Истинската работа на стека е да направи смяната на мнението евтина. Зрелите, добре документирани инструменти с големи общности ви позволяват да се движите бързо, защото отговорите на проблемите ви вече съществуват. Свръхновите инструменти ви правят човекът, който открива бъговете.

Дали можете да наемате за него. Изберете нещо неясно и обвързвате бъдещето си с този, който го е изградил. Изберете нещо разпространено и скучно и винаги ще намерите следващия разработчик, следващата агенция, следващия човек, който да поеме. Скучното е предимство, когато бизнесът ви зависи от него.

Какво има далеч по-малко значение, отколкото казват

Чистата производителност и „мащабът“. Нямате проблем с мащаба. Имате проблем, че никой още не го ползва, което е обратният проблем. Архитектури, проектирани за милиони потребители, ще ви забавят, когато имате единайсет. Прочутите компании, които имитирате, първо изградиха простата версия и я преизградиха по-късно, финансирани от успеха. Така трябва и вие.

Коя точно рамка „печели“ тази година. Рамките се издигат и падат в моден цикъл, който почти няма нищо общо с това дали ще изградят добре вашия SaaS за фактуриране. Всяка от масовите, широко използвани опции ще свърши работа. Тенденцията е шум; изберете от скучната, популярна среда и продължете нататък.

Защо „скучната“ технология обикновено побеждава

Сред опитните строители има тиха мъдрост, която новодошлите намират за разочароваща: най-добрата технология за нов бизнес обикновено е скучната, доказана, леко немодна. Не защото новите инструменти са лоши, а защото всеки избор харчи от ограничен бюджет от новост — броя непознати, неподдържани, изненадващи неща, които малкият ви екип може да поеме наведнъж.

Похарчете този бюджет за нещото, което прави бизнеса ви специален — самия продукт, прозрението, което имате само вие. Не го харчете за база данни, за която никой не е чувал, само за да се чувствате модерни. Скучен, зрял стек означава, че проблемите вече са решени, документацията съществува, наемането е лесно и инструментът няма да изчезне догодина, когато единственият му поддръжник изгуби интерес. Скучното ви позволява да насочите цялото си вълнение там, където то се отплаща: към клиента.

Надеждна, леко старомодна наковалня или здрав работен тезгях, окъпани в топла светлина, до бляскаво, но крехко неоново джунджурийче, което примигва — визуална метафора за скучни доказани инструменти срещу модерни чупливи, редакционен плосък стил
Вълнуващият инструмент е забавен, докато не се счупи посред нощ и няма кого да попиташ. Скучните инструменти имат наръчник.

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

Метод за решаване, който наистина можете да ползвате

Достатъчно принципи. Ето конкретен начин да стигнете до решение, независимо дали избирате сами, инструктирате фрийлансър или оценявате какво предлага агенция. Нищо от това не изисква да пишете код — само да питате правилните неща и да претеглите отговорите.

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

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

Въпроси към всеки, който предлага стек

Повечето основатели не избират стека сами — разработчик, агенция или приятел CTO предлага. Не е нужно сами да проверявате технологията. Нужно е да зададете шепа въпроси и да слушате как отговарят. Уверените отговори на прост език са добър знак. Защитният жаргон — не.

  • „Защо точно това, а не скучната популярна опция?“ — добрият отговор е за вашите конкретни нужди, не за това какво е модерно.
  • „Ако те блъсне автобус, колко лесно някой друг ще поеме това?“ — отговорът разкрива колко рядък и рисков е изборът.
  • „Коя е най-простата версия на тази архитектура, която още работи?“ — гледайте дали посягат към простота или към сложност.
  • „Колко лесно ще е да наемем следващия разработчик за това?“ — масовите умения значат здрав пазар; екзотичните — зависимост.
  • „Какво става, когато след три месеца трябва да сменим основна функция?“ — искате да чуете, че промяната е евтина, не страховита.
Спокоен разговор през маса между нетехнически основател и разработчик, основателят държи кратък списък с въпроси, и двамата отпуснати и в сътрудничество, топла естествена светлина, редакционна плоска илюстрация
Не е нужно да знаете отговорите — нужно е да задавате въпросите и да забележите как се отговаря на тях.

Често срещани капани, които изглеждат като добри идеи

Няколко модела се срещат толкова често, че си заслужава да бъдат назовани, защото всеки от тях изглежда отговорен в момента и ви струва скъпо по-късно.

Изграждане за мащаб, който нямате. Подтикът да „го направим както трябва“ кара основателите да проектират за милиони потребители, преди да имат десет. Всяка частица от това подготвяне за бъдещето е сложност, която плащате сега, във време и пари, за да решите проблем, който може и да не дойде. Изграждайте за следващите сто потребители. Преархитектурирайте, когато растежът го наложи — и нека това е щастлив проблем.

Гонене на най-новото. Бляскава рамка, излязла миналия месец, няма история, има оскъдна документация и мъничка общност. Ще прекарвате нощите си в дебъгване на инструмента вместо в изграждане на продукта. Оставете други да са ранните последователи; вие имате бизнес за пускане.

Възлагане на най-евтиния, на каквото той предпочита. Най-ниската оферта често идва с неясен стек, който знае само онзи екип. В деня, в който се разделите, продуктът ви става остров, до който никой друг не може да стигне. Евтино в началото, гибелно по-късно. Настоявайте за масова, наемаема технология, дори когато възлагате — особено когато възлагате.

Правилният стек е този, който непознат може да подхване и да продължи. Ако само човекът, който го е изградил, го разбира, не притежавате продукт — притежавате зависимост.
тестът, който хваща повечето лоши избори

Кога наистина е време да преразгледате стека си

Нищо от това не значи „никога не променяй“. Значи променяй по реални причини, измерени, не въобразени. Ще разберете, че наистина е време да развиете стека си, когато се появят конкретни сигнали — не когато някоя статия в блог ви разтревожи.

СигналРеална причина за промяна?Какво да направите
Приложението е измеримо бавно за реални потребителиДаПърво измерете, после поправете конкретното тясно място
Добавянето на функции става все по-бавноДаОпростете или рефакторирайте болезнената част
Не можете да наемете никого, който го знаеДаПланирайте съзнателна миграция към масови инструменти
Конкурент ползва по-моден стекНеИгнорирайте — стекът им не е тяхното предимство
Излезе нова рамка и изглежда якоНеЗапазете я в отметките, продължете да пускате
На инженер просто му е скучноНеАдресирайте духа, не архитектурата
Сигнали, че първият ви стек наистина се надраства — срещу шум, който само изглежда спешен.

Забележете модела: реалните причини са за измерена болка в реалния ви бизнес. Фалшивите причини са за мода, сравнение и неспокойствие. Когато наистина се появи реален сигнал, променяте по едно парче — а не целия стек в героично пренаписване, което спира всичко за шест месеца. Еволюция, не революция.

Искате второ мнение, преди да се обвържете?

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

Вижте как изграждаме софтуер

Често задавани въпроси

Има ли един най-добър технологичен стек за SaaS стартъп?
Не, и всеки, който каже „да“, без да познава бизнеса ви, гадае. Най-добрият стек е този, който екипът ви може да изгражда и поддържа свободно, направен от масови, добре поддържани инструменти, върху най-простата архитектура, която работи. За повечето първи SaaS продукти това значи една популярна фронтенд рамка, един бекенд, една релационна база данни като Postgres и стандартен облачен хостинг — но конкретните имена имат далеч по-малко значение от принципите.
Трябва ли да ползвам най-новата, най-модерна рамка?
Обикновено не за първия си продукт. Новите рамки имат оскъдна документация, малки общности и неоткрити бъгове, което значи, че прекарвате нощите си в поправяне на инструмента вместо в изграждане на бизнеса. Изберете нещо доказано и леко скучно; ще се движите по-бързо и ще намирате помощ — човешка и от ИИ — далеч по-лесно. Оставете други да са ранните последователи.
Трябват ли ми микросървиси или „мащабируема“ архитектура от първия ден?
Почти сигурно не. Микросървисите и заплетените мащабируеми настройки решават проблеми с голям мащаб, които още нямате, докато добавят сложност, която малък екип не може да си позволи. Започнете с един прост бекенд и база данни. Компаниите, на които се възхищавате, първо изградиха простата версия и я преархитектурираха по-късно, финансирани от успеха си. Така трябва и вие.
Как да преценя стек, ако не съм технически?
Не преценявате технологията директно — преценявате отговорите. Попитайте този, който я предлага, защо я е избрал, колко лесно някой друг би я поел, колко проста може да бъде и колко лесно е да се наема за нея. Слушайте за отговори на прост език, осъзнаващи компромисите. Уверен жаргон, който избягва въпроса ви, е предупредителен знак; честното „зависи“ е успокояващо.
Ами ако избера грешно — заклещен ли съм завинаги?
Не. Софтуерът не е основа, която изливате веднъж; той е по-скоро кухня, която можете да преобзаведете, докато готвите. Стековете биват частично пренаписвани с растежа на продуктите и това е нормално, не провал. Стига да сте избрали масови, наемаеми инструменти и да сте държали нещата прости, смяната на посоката по-късно е управляема работа парче по парче — не катастрофа.
Have a nice day
Have a nice day
Редакция

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

Подходящи услуги