SaaS-архитектура для соло-фаундеров: скучное — это стратегия
Архитектурные решения, которые позволяют одному человеку строить, запускать и масштабировать SaaS, — и модные выборы, которые тихо убивают соло-проекты.
Pavel Duglas
AI Automation & MVP Architect
Каждый соло-SaaS, умерший по техническим причинам, умирает одинаково: не от недостатка инженерии, а от её избытка. Архитектурный плейбук продукта одного человека противоположен тому, что оптимизируют доклады на конференциях, — и именно в этом его сила.
Ограничение, которое определяет всё
Вы — не маленькая команда. Вы — один мозг, который должен одновременно держать продукт, поддержку, маркетинг и инфраструктуру. Каждое архитектурное решение оценивайте одним вопросом: сколько моего мозга это арендует навсегда?
Kubernetes арендует много мозга. Монолит на managed-платформе — почти нисколько.
Скучный стек, с обоснованием
- Монолит. Одна кодовая база, один деплой, один поток логов, который можно читать в два часа ночи, когда что-то сломалось. Сервисы можно выделить позже, если успех потребует, — это хорошая проблема, запланированная на более богатое будущее.
- PostgreSQL для всего. Очередь? Таблица. Кэш? Таблица (или Redis, когда измеренная боль скажет). Поиск? Полнотекстовый Postgres, пока не доказано обратное. Каждое дополнительное хранилище — новый режим отказа, который принадлежит лично вам.
- Managed-сервисы для всего стейтфул. Базы, файлы, почта, платежи. Часы, не потраченные на скрипты бэкапов, становятся часами продукта.
- Серверный рендеринг плюс щепотка JS. SaaS-дашборду редко нужен SPA. Ему нужны работающие формы и быстрые страницы.
Скучное не значит любительское. Это значит, что у каждого компонента режимы отказа задокументированы, гуглятся и переживаемы одним человеком.
Куда действительно тратить сложность
У соло-продукта есть бюджет сложности, и тратить его нужно там, где видно клиентам:
- Модель данных. Ошибки схемы — самые дорогие к исправлению на двенадцатом месяце. Здесь думайте долго.
- Крайние случаи биллинга. Триалы, апгрейды, неудачные платежи, возвраты. Это настоящая инженерия, и экономия здесь создаёт нагрузку на поддержку навсегда.
- Одна функция, которая выигрывает сделки. То, из-за чего первые клиенты сказали «да», заслуживает в десять раз больше полировки, чем всё остальное.
- Наблюдаемость. Трекинг ошибок и ежедневное письмо с метриками. Нельзя починить то, чего не видишь, — а кроме вас не смотрит никто.
Тихие убийцы
- Преждевременная мультитенантная хитрость — отдельные базы на клиента до десятого клиента.
- Зуд переписывания — версия два стека вместо версии два продукта.
- Выбор ради резюме — технология, которую хочется выучить, на продукте, который платит за вашу аренду.
Тест
Хорошая соло-архитектура проходит один тест: её можно оставить на две недели, вернуться и безопасно продолжить в течение часа. Если ваш стек этот тест не проходит, неважно, насколько он современный, — он владеет вами, а не наоборот.
Стройте скучно. Продавайте захватывающе. В этом вся стратегия.
Связанные услуги
Вопросы и ответы
Какой стек вы рекомендуете соло-фаундеру SaaS?
Тот, который вы уже знаете, собранный просто: монолит, PostgreSQL, managed-хостинг и Stripe. Ваше отличие — продуктовая логика, а не выбор инфраструктуры.
Когда соло-SaaS действительно нужны микросервисы?
Почти никогда. Микросервисы решают проблемы координации команд. У команды из одного человека нет проблемы координации — дробление сервисов лишь умножает поверхность деплоя и отладки.