Стек для micro SaaS в одиночку

Стек для micro SaaS выбирается по одному критерию: что вы почините быстрее всего сами. Чинить будете вы, ночью, по логам, без второго человека, которому можно написать «глянь, пожалуйста». Скорость фреймворка и его свежесть на этом фоне — темы для команд, где есть кому дежурить.

В одиночку выбор сводится к трём вопросам и короткому списку того, чего в стеке быть не должно.

Три вопроса к каждому пункту стека

1. Чинил ли я это раньше сам? Не «читал статью», а поднимал после падения. Незнакомая технология в проекте — это не ноль опыта, это минус несколько вечеров в тот момент, когда их точно не будет.
2. Сколько часов уйдёт на замену? Сервис, который вы не сможете заменить за выходные, становится вашим владельцем. Это не повод избегать внешних сервисов, это повод знать цену выхода заранее.
3. Как это откатывается? Если ответа «одной командой» нет, вы не будете выкатывать изменения по вечерам. А выкатывать придётся часто.

Что стоит у меня

Слой	Что взял	Почему
Сайт	Astro, статика	нет базы и нет рантайма — нечему падать
Деплой	astro build и rsync на сервер	одна команда, откат — предыдущая папка
Сервер	VPS в России, nginx	конфиг на двадцать строк, лежит в репозитории
Скрипты	Python без зависимостей	пишу быстрее всего, ставится везде
Разработка	Claude Code в терминале	код остаётся в репозитории, а не в чужом редакторе

Сборка сайта требует Node 22, на Node 20 она падает. Я знаю это, потому что однажды потратил на выяснение вечер, и теперь версия зафиксирована в репозитории. Такие мелочи и есть настоящая цена стека, и их тем больше, чем экзотичнее выбор.

Базы данных в списке нет: сайту она не нужна. Она появится вместе с первым продуктом, и это будет PostgreSQL на том же сервере — по тому же принципу, по которому выбрано всё остальное.

Чего в стеке нет и почему

• Kubernetes и оркестрация. Инструмент для десятков сервисов и дежурной смены. Для одного процесса это дополнительный слой, который отказывает отдельно от вашего кода.
• Микросервисы. Разделение на сервисы оплачивается сетевыми ошибками, общими схемами и отладкой между процессами. У одного разработчика нет границ команд, ради которых это разделение придумано.
• Очередь задач до первой нагрузки. Пока задач десятки в день, их выполняет cron и таблица в базе. Брокер сообщений добавляется, когда появляется реальный поток.
• Отдельное SPA-приложение. Второй проект, вторая сборка, второй набор зависимостей. Серверный рендер плюс немного JavaScript закрывает интерфейс первых версий целиком.
• Своя аналитика и свой мониторинг. Логи nginx и доступ по почте при падении дают девяносто процентов пользы за несколько строк конфигурации.

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

Где держать сервер

Для сервиса, который берёт деньги с российских клиентов, вопрос решается не удобством панели. Три вещи, которые стоит выяснить до выбора площадки: где по закону должны храниться персональные данные ваших пользователей (смотрите текст 152-ФЗ, а не пересказы), примет ли платёжный провайдер сервис на зарубежном хостинге, и чем вы будете платить за сервер, если карта перестанет проходить.

Я держу сайт на VPS в России: оплата в рублях, поддержка отвечает по-русски, и к платёжному провайдеру нет лишних вопросов. Минус честный — до читателей из Европы пинг заметно хуже, но для текстового сайта это не тот параметр, ради которого стоит усложнять.

Где стек и языковая модель связаны

Модель хорошо пишет то, чего много в открытом коде: популярные фреймворки, стандартные библиотеки, типовые схемы. На редком стеке она начинает выдумывать функции, которых нет, и вы тратите время на проверку вместо экономии.

Это ещё один аргумент за скучный выбор. Но он не отменяет правила из разбора про разработку с LLM: код, который вы не сможете починить ночью по логам, в прод не идёт, кем бы он ни был написан.

Что не экономится

Три вещи стоят копейки и не режутся ни при каком бюджете.

Бэкапы. Не часть стека в обычном смысле, но без них всё остальное не имеет значения. Бэкап, из которого вы ни разу не восстанавливались, бэкапом не является — проверка занимает полчаса и делается до первого клиента.

Свой домен и почта на нём. Письмо с адреса на бесплатном домене снимает половину доверия в переписке с компанией. Стоимость — в смете.

Логи, которые вы читаете. Логи, в которые никто не заглядывает, эквивалентны их отсутствию. Достаточно, чтобы при ошибке приходило письмо, а в логе было видно, какой запрос её вызвал.

Чек-лист перед первой строкой кода

1. Каждый пункт стека я уже поднимал руками хотя бы раз.
2. Деплой — одна команда.
3. Откат — одна команда или переименование папки.
4. Версии языка и сборщика зафиксированы в репозитории.
5. Конфиг сервера лежит в репозитории, а не только на сервере.
6. Бэкап настроен и один раз восстановлен.
7. При ошибке в проде мне приходит письмо.
8. Я могу поднять всё с нуля на новом сервере за вечер.

Восьмой пункт проверяет остальные семь: если поднять с нуля не получается, где-то остался шаг, который живёт только у вас в голове.

Что дальше

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

Что из этого получается у меня — на странице проектов и в заметках. Спорите с выбором или собираете свой стек — пишите в телеграм.

Частые вопросы

На чём писать micro SaaS в одиночку?

На том, что вы уже чините без документации. Язык и фреймворк почти не влияют на успех продукта, а скорость починки в два часа ночи влияет напрямую: чинить некому, кроме вас.

Нужен ли Docker и Kubernetes для одного сервиса?

Kubernetes — нет, это инструмент для команд и десятков сервисов. Docker может пригодиться для одинакового окружения на ноутбуке и сервере, но если деплой и без него укладывается в одну команду, добавлять его на старте незачем.

Какую базу данных брать?

PostgreSQL на том же сервере или SQLite, если сервис однопроцессный. Выбор базы почти никогда не становится причиной провала micro SaaS, а вот отсутствие проверенных бэкапов становится.

Стоит ли писать свою авторизацию?

Регистрацию по почте и ссылку для входа написать проще, чем кажется, а вот хранение паролей, сброс и защиту от перебора лучше не изобретать. Если в продукте нет требования к своей авторизации, берите готовую библиотеку своего фреймворка.

Как языковая модель влияет на выбор стека?

Модель пишет мейнстримные стеки заметно лучше редких: на популярном фреймворке она выдаёт рабочий код, на экзотике выдумывает несуществующие функции. Это аргумент за скучный выбор, но проверять её код всё равно придётся вам.

← База знаний