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

Контекст

К нам приходят основатели на стадии MVP и продуктовые команды, которые упёрлись в потолок шаблонных решений. Часто у них уже есть Notion-доска с фичами, но нет ответа на вопрос: где данные тенанта изолированы, как считается биллинг по тарифам, что произойдёт при отказе платежа и как обновлять схему БД без даунтайма. Эти вопросы и формируют архитектуру.

Подход

Мы начинаем с domain modeling: разбираем сущности (account, workspace, subscription, usage), рисуем границы транзакций и определяем, что попадает в core, а что — в side-services. Только после этого выбираем стек. Для большинства SaaS-кейсов мы используем монолит на TypeScript с чёткой модульной структурой, PostgreSQL с row-level security для изоляции тенантов, очередями на BullMQ для фоновых задач и Stripe для биллинга. Фронтенд — Astro для маркетинга и React/Next для приложения, если оно SPA-heavy.

Что мы делаем

  • Domain modeling и описание границ тенантов до старта кода
  • Аутентификация: passwordless, SSO, MFA — с самого начала, не как post-MVP фича
  • Биллинг: Stripe Subscriptions с правильной обработкой webhook-событий и идемпотентностью
  • Observability: structured logs, метрики, трассировка запросов между сервисами
  • Миграции БД через инструменты, поддерживающие zero-downtime схемы
  • Feature flags для постепенного раскатывания функций по тенантам

Чему научились

Главный урок — мульти-тенантность нельзя добавить «потом». Если в первой версии данные одного клиента случайно увидит другой, доверие восстановить почти невозможно. Поэтому row-level security и автоматические тесты на изоляцию тенантов — это не over-engineering, а минимально жизнеспособный фундамент. Второй урок — биллинг ломается чаще, чем кажется: failed payments, прокси-карты, валютные различия, налоги. Хороший биллинг означает, что у вас всегда есть единый источник правды о состоянии подписки, и он сходится с тем, что показывает Stripe.

Что дальше

Если вы строите SaaS и хотите второе мнение по архитектуре — напишите нам через /contacts. Разберём ваш случай, обозначим риски и предложим маршрут от MVP до устойчивого продукта.