Выбор стека технологий для вашего первого SaaS: честное руководство для основателя
Большинство споров о стеке — это религиозные войны между инженерами, которые никогда не воспользуются вашим продуктом. Это спокойная версия: как нетехнический основатель выбирает стек, который позволяет выпустить SaaS с платящими клиентами и всем прочим, не ставя на кон всю компанию ради тренда.

Спросите десять инженеров, какой стек технологий использовать для вашего первого SaaS, и вы получите пятнадцать ответов, три из которых будут произнесены с уверенностью вероисповедания. Большинство этих ответов верны — для того, кто их даёт. Ни один из них не о вас, не о вашем запасе денег и не о клиентах, которых вы ещё не привлекли. Если вы как основатель смотрите на это решение и чувствуете лёгкую дурноту, вот то, что никто не произносит вслух: стек значит гораздо меньше, чем вам внушили, а те немногие способы, которыми он всё же значим, — не те, о которых спорят в сети.
Я помог немалому числу начинающих основателей пройти путь от презентации до продукта, за который платят реальные люди. Почти никто из них не был техническим. Почти все приходили, уже впитав пугающее количество фольклора о стеках — что им нужны микросервисы, что один фреймворк «мёртв», что неверный выбор их погубит. И почти всякий раз стек оказывался одним из наименее значимых решений, принятых ими за тот год. Проекты губили объём работ, неясная ответственность и красивое создание не того, что нужно. Никогда не фреймворк.
Так что это руководство, которое я даю этим основателям, прежде чем мы напишем хоть строчку кода. Оно не скажет вам использовать один конкретный стек, потому что всякий, кто обещает это, не зная вашего бизнеса, что-то продаёт. Вместо этого оно даст способ мыслить — чтобы, что бы вы ни выбрали или что бы ни предложила ваша команда, вы могли проверить это как взрослый человек, а не нервно кивать в ответ.
Почему это решение кажется труднее, чем оно есть
Вопрос о стеке кажется огромным, потому что это первый звучащий необратимо выбор, который вы делаете, и он завёрнут в язык, которым вы не владеете. Слова вроде Postgres, React, Kubernetes, serverless разбрасываются так, будто выбор между ними — как выбор фундамента здания: ошибётесь, и всё рухнет.
Но программное обеспечение — не здание. Оно гораздо ближе к кухне, которую можно переделывать, не прекращая готовить. Успешные компании постоянно переписывают части своего стека; версия продукта, находящая первую сотню клиентов, почти никогда не та версия, что обслуживает первую сотню тысяч. Цель вашего первого стека — не прожить вечно. Она в том, чтобы дать вам строить, менять и выпускать достаточно быстро, чтобы узнать, нужно ли это вообще кому-нибудь. Это совершенно иная — и куда более низкая — планка, чем «идеально на следующее десятилетие».
“Ваш первый стек не обязан быть тем, на котором вы будете масштабироваться. Он должен быть тем, который позволит выяснить, является ли масштабирование вообще проблемой, которую стоит иметь.”
Как только вы это примете, давление спадает вдвое. Вы больше не пытаетесь предсказать будущее. Вы пытаетесь сделать разумную, обратимую ставку, которая приведёт вас к работающему продукту и платящим пользователям. А разумные ставки — это как раз то, что нетехнический основатель вполне способен оценить.
Что такое «стек» на самом деле, простыми словами
Прежде чем что-либо решать, полезно развенчать это слово. Стек технологий — это просто набор инструментов, используемых для создания и запуска вашего ПО. Его можно представить в четырёх слоях, и ни один из них не нужно понимать глубоко — достаточно знать, что они существуют.
- Фронтенд — то, что пользователи видят и нажимают в браузере или приложении. Это та часть, по которой вас все судят.
- Бэкенд — логика и правила, работающие на сервере: кто что может делать, что происходит, когда они это делают, как движутся деньги.
- База данных — где на самом деле живёт ваша информация: пользователи, заказы, подписки, всё, потерю чего вы переживали бы тяжелее всего.
- Инфраструктура — серверы и сервисы, которые держат всё вышеперечисленное в сети, в резервных копиях и доступным в три часа ночи.
Когда кто-то говорит «мы используем современный стек JavaScript» или «Rails на Postgres», он описывает выборы по этим четырём слоям. И всё. Любой SaaS, от пет-проекта двух человек до публичной компании, — это некая версия этих четырёх вещей, сложенных вместе. Грандиозно звучащие диаграммы архитектуры — это ровно то же самое, нарисованное большим числом квадратиков.

То, что действительно важно (и то, что нет)
Вот где большинство советов о стеке сбивается с пути: они оптимизируют под то, что не влияет на ваши первые два года, и игнорируют то, что влияет. Позвольте мне быть прямым насчёт обоих списков.
Что действительно важно
Кто может это построить и поддерживать. Единственный важнейший фактор — не технология, а люди. Лучший стек для вас — тот, в котором ваша команда (или нанятый вами партнёр) действительно может свободно работать уже сегодня. «Идеальный» стек, который понимает лишь один редкий специалист, — худший выбор, чем скучный, который подхватит любой грамотный разработчик. Наём и преемственность всякий раз бьют теоретическую элегантность.
Как быстро вы можете менять. На раннем этапе вы будете постоянно ошибаться насчёт своего продукта. Настоящая задача стека — сделать смену мнения дешёвой. Зрелые, хорошо документированные инструменты с большими сообществами позволяют двигаться быстро, потому что ответы на ваши проблемы уже существуют. Инструменты на острие прогресса делают вас тем, кто обнаруживает баги.
Можете ли вы нанять под это людей. Выберите что-то малоизвестное — и привяжете своё будущее к тому, кто это построил. Выберите что-то распространённое и скучное — и вы всегда найдёте следующего разработчика, следующее агентство, следующего человека, чтобы передать дело. Скучное — это достоинство, когда от него зависит ваш бизнес.
Что значит гораздо меньше, чем говорят
Чистая производительность и «масштаб». У вас нет проблемы масштаба. У вас проблема пока-никто-этим-не-пользуется, что является противоположной проблемой. Архитектуры, спроектированные на миллионы пользователей, затормозят вас, когда у вас их одиннадцать. Знаменитые компании, которым вы подражаете, сначала построили простую версию, а перестроили позже, профинансировав это успехом. Вам стоит сделать так же.
Какой именно фреймворк «побеждает» в этом году. Фреймворки взлетают и падают по циклу моды, который почти никак не связан с тем, хорошо ли они построят ваш SaaS для выставления счетов. Любой из распространённых, широко используемых вариантов справится с задачей. Тренд — это шум; выберите из скучной, популярной середины и двигайтесь дальше.
Почему «скучная» технология обычно побеждает
Среди опытных создателей есть тихая мудрость, которую новички находят разочаровывающей: лучшая технология для нового бизнеса обычно скучная, проверенная, чуть немодная. Не потому, что новые инструменты плохи, а потому, что каждый ваш выбор расходует ограниченный бюджет новизны — число незнакомых, неподдерживаемых, неожиданных вещей, с которыми ваша маленькая команда может справиться одновременно.
Потратьте этот бюджет на то, что делает ваш бизнес особенным, — на сам продукт, на инсайт, который есть только у вас. Не тратьте его на базу данных, о которой никто не слышал, лишь бы почувствовать себя современным. Скучный, зрелый стек означает, что проблемы уже решали раньше, документация существует, нанимать легко, а инструмент не исчезнет через год, когда его единственный сопровождающий потеряет интерес. Скучное позволяет вложить весь энтузиазм туда, где он окупается: в клиента.

Здесь же ИИ слегка меняет картину — и не так, как намекает хайп. ИИ-ассистенты для кода значительно лучше справляются со скучными, популярными технологиями, потому что их обучали на десятилетии публичных ответов о них. Выберите распространённый стек — и ваша команда (и ваши инструменты) бесплатно получат более быструю помощь. Выберите что-то экзотическое — и вы останетесь одни ровно тогда, когда меньше всего можете себе это позволить.
Метод принятия решения, которым действительно можно пользоваться
Хватит принципов. Вот конкретный способ прийти к решению, выбираете ли вы сами, инструктируете фрилансера или оцениваете предложение агентства. Ничто из этого не требует писать код — только задавать правильные вопросы и взвешивать ответы.
- 1Начните с команды, а не с технологииСпросите: кто будет строить и поддерживать это следующие два года? То, что они уже хорошо знают, — ваш сильный вариант по умолчанию. Смена стека ради погони за трендом редко превосходит свободное владение.
- 2По умолчанию выбирайте распространённое и проверенноеВыбирайте из популярной, хорошо документированной середины каждого слоя. Если вы не можете быстро найти для инструмента руководства, вакансии и большие сообщества, считайте это предупреждением, а не достоинством.
- 3Оптимизируйте под изменение, а не под масштабОтдавайте предпочтение выбору, который делает редактирование продукта дешёвым и быстрым. Вы будете раз за разом ошибаться насчёт продукта — задача стека в том, чтобы ошибки можно было пережить.
- 4Держите архитектуру максимально простойОдна база данных. Один бэкенд. Один фронтенд. Никаких микросервисов, никакого хитрого распределённого чего-либо, пока реальная, измеренная проблема не вынудит вас. Простота — это цель, а не компромисс.
- 5Запишите, почему вы это выбралиОдин абзац: кто строит, что вы выбрали и что должно измениться, чтобы вы это пересмотрели. Эта заметка избавит вас от пересмотра решения всякий раз, когда кто-то прочитает горячее мнение.
Если вы не последуете ничему другому, последуйте шагам один и четыре. Стройте с людьми, которые у вас есть, на самой простой работающей архитектуре. Это сочетание тихо обходит два режима провала, топящие большинство первых SaaS-продуктов: некому поддерживать и система слишком сложна для своего размера.
Вопросы тому, кто предлагает стек
Большинство основателей не выбирают стек в одиночку — его предлагает разработчик, агентство или знакомый технический директор. Вам не нужно проверять технологию самостоятельно. Нужно задать несколько вопросов и послушать, как отвечают. Уверенные ответы на простом языке — хороший знак. Защитный жаргон — нет.
- «Почему это, а не скучный популярный вариант?» — хороший ответ о ваших конкретных потребностях, а не о том, что модно.
- «Если бы вас сбил автобус, насколько легко кто-то другой смог бы это перенять?» — ответ раскрывает, насколько редок и рискован выбор.
- «Какая самая простая версия этой архитектуры, которая всё ещё работает?» — смотрите, тянутся ли они к простоте или к сложности.
- «Насколько легко будет нанять следующего разработчика под это?» — распространённые навыки означают здоровый рынок; экзотические означают зависимость.
- «Что произойдёт, когда через три месяца нам понадобится изменить ключевую функцию?» — вы хотите услышать, что изменение дёшево, а не пугает.

Частые ловушки, которые выглядят как хорошие идеи
Несколько шаблонов встречаются так часто, что их стоит назвать, потому что каждый кажется ответственным в моменте, а позже дорого вам обходится.
Строить под масштаб, которого у вас нет. Желание «сделать как следует» побуждает основателей проектировать под миллионы пользователей, когда у них их десять. Каждая крупица этой защиты от будущего — сложность, за которую вы платите сейчас, временем и деньгами, чтобы решить проблему, которая может никогда не наступить. Стройте под следующую сотню пользователей. Перепроектируйте, когда рост это потребует, — и пусть это будет приятная проблема.
Гнаться за самым новым. Блестящий фреймворк, вышедший в прошлом месяце, не имеет послужного списка, у него скудная документация и крошечное сообщество. Вы будете проводить ночи, отлаживая инструмент вместо того, чтобы строить продукт. Пусть другие будут ранними последователями; у вас есть бизнес, который нужно выпустить.
Отдавать на аутсорс тому, кто дешевле, на том, что он предпочитает. Самое низкое предложение часто идёт с малоизвестным стеком, который знает лишь та одна команда. В день, когда вы расстанетесь, ваш продукт станет островом, до которого никто другой не доберётся. Дёшево вначале, разорительно потом. Настаивайте на распространённой, доступной для найма технологии даже когда отдаёте на аутсорс — особенно когда отдаёте на аутсорс.
“Правильный стек — тот, что незнакомец мог бы подхватить и продолжить. Если его понимает лишь тот, кто его построил, у вас не продукт — у вас зависимость.”
Когда действительно пора пересмотреть стек
Ничто из этого не означает «никогда не менять». Это означает менять по реальным причинам, измеренным, а не воображаемым. Вы поймёте, что и правда пора развивать стек, когда появятся конкретные сигналы, — а не когда пост в блоге вызовет у вас тревогу.
| Сигнал | Реальная причина менять? | Что делать |
|---|---|---|
| Приложение измеримо медленное для реальных пользователей | Да | Сначала измерьте, исправьте конкретное узкое место |
| Добавлять функции становится всё медленнее | Да | Упростить или отрефакторить болезненную часть |
| Вы не можете нанять никого, кто это знает | Да | Спланировать осознанную миграцию на распространённые инструменты |
| Конкурент использует более модный стек | Нет | Игнорировать — их стек не их преимущество |
| Вышел новый фреймворк и выглядит круто | Нет | Добавить в закладки, продолжать выпускать |
| Инженеру просто скучно | Нет | Заняться боевым духом, а не архитектурой |
Заметьте закономерность: реальные причины — об измеренной боли в вашем фактическом бизнесе. Ложные причины — о моде, сравнении и беспокойстве. Когда реальный сигнал всё же появляется, вы меняете по одной части за раз — а не весь стек в героическом переписывании, которое застопорит всё на полгода. Эволюция, а не революция.
Хотите второе мнение, прежде чем взять на себя обязательства?
Выбрать стек — или проверить тот, что кто-то предложил, — гораздо чаще оказывается задачей на один разговор, чем основатели ожидают. Мы с радостью посмотрим на вашу идею и честно скажем, что стоит строить, как и что держать простым.
Посмотрите, как мы создаём ПОЧастые вопросы
Существует ли единственный лучший стек технологий для SaaS-стартапа?
Стоит ли использовать самый новый, самый современный фреймворк?
Нужны ли мне микросервисы или «масштабируемая» архитектура с первого дня?
Как оценить стек, если я не технический человек?
А если я выберу неправильно — застряну ли я навсегда?

Have a nice day — это софтверная студия, которая помогает малому и среднему бизнесу перейти в цифру: автоматизация, ИИ и софт под заказ, который работает в повседневных процессах, а не только на слайдах.