SaaS-разработка

Разработка и развитие SaaS-продуктов: архитектура, биллинг и метрики

Помогаем продуктовым командам с тем, что определяет судьбу SaaS: архитектура и мультитенантность, изоляция данных, биллинг и монетизация, безопасность и комплаенс, интеграции и сопровождение.

Сначала архитектура, потом экраны

Мультитенантность, изоляцию данных и биллинг проектируем до первой строки кода
Смета и срок до договора

Объём первой версии фиксируем после разбора продукта и метрик
Решения по метрикам, а не по ощущениям

MRR, отток, LTV и окупаемость привлечения — основа для выбора функций
Код, инфраструктура и аккаунты — ваши

Репозиторий, облако, домены и платёжные аккаунты оформляются на вас

Обсудить продукт Посчитать экономику

Панель вендора · подписки

MRR

588 000 ₽

активных: 120

янвфевмарапрмайиюниюл

ООО «Северный лес»

Тариф «Бизнес»

48 900 ₽
ИП Ковалёв

Тариф «Старт»

7 400 ₽
ООО «Агро-Плюс»

Тариф «Бизнес»

48 900 ₽
ООО «ТехноСервис»

Usage-based

112 300 ₽

Изоляция данных

tenant_id в каждой таблице

область видимости задана на уровне модели

Отток платежей

повторные попытки и дозвоны

сверка с подписками автоматическая

Laravel Livewire PostgreSQL Redis Horizon Octane Docker мультитенантность usage-based биллинг Stripe ЮKassa СБП рекуррентные платежи SSO и OAuth2 вебхуки очереди S3 Grafana Sentry 1С Битрикс24 Email и SMS

Экономика продукта до разработки

Прежде чем выбирать функции, стоит понять, из чего складывается выручка и где она теряется. Двиньте ползунки под свои цифры — модель посчитает выручку, срок жизни клиента и окупаемость привлечения. Расчёт идёт в браузере, ничего никуда не отправляется.

Параметры продукта

Платящих клиентов 120

52 000

Средний чек в месяц, ₽ 4 900 ₽

500 ₽100 000 ₽

Отток клиентов в месяц, % 2,5 %

0,2 %10 %

Расширение выручки на клиента, % в месяц 1,5 %

0 %8 %

Стоимость привлечения клиента, ₽ 18 000 ₽

0 ₽200 000 ₽

Инфраструктура на клиента, ₽ в месяц 900 ₽

0 ₽20 000 ₽

Выручка в месяц (MRR)

588 000 ₽

Годовая выручка по текущему темпу: 7 056 000 ₽

Срок жизни клиента: 40,0 мес.
Валовая маржа: 81,6 %
LTV клиента: 160 000 ₽
LTV / CAC: 8,9 ×
Окупаемость привлечения: 4,5 мес.
Удержание выручки, NRR за год: 88 %

Как читать. LTV считается с учётом валовой маржи, NRR — как произведение удержания и расширения за двенадцать периодов; это ориентировочная модель, а не прогноз. Если LTV/CAC ниже 3, экономика обычно не выдерживает роста: сначала имеет смысл работать над удержанием и стоимостью привлечения, а не над новыми функциями.

Мультитенантность: четыре модели и их цена

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

Общая база и tenant_id в каждой таблице

Кому подходит: Массовые B2B- и B2C-продукты: тысячи небольших аккаунтов, стоимость инфраструктуры на клиента критична
Изоляция данных: Логическая: строки разделяются идентификатором клиента. Требует дисциплины — глобальных ограничений выборки на уровне модели, а не «не забыть в where»
Стоимость эксплуатации: Самая низкая: одна база, одна схема, один набор миграций
Сложность миграций: Простые: миграция выполняется один раз для всех клиентов

Главный риск модели

Одна забытая область видимости в запросе — и клиент увидит чужие данные. Ошибка стоит дороже всего

Подробнее о выборе и ограничениях читайте в статье Мультитенантная архитектура SaaS и в материале про изоляцию данных клиентов.

Отдельная схема в общей базе на каждого клиента

Кому подходит: B2B среднего размера: нужна изоляция данных и при этом единая кодовая база и один сервер
Изоляция данных: Средняя: данные клиента лежат в своей схеме, доступ разграничен правами базы
Стоимость эксплуатации: Средняя: одна база, но сотни схем и соединений
Сложность миграций: Сложнее: каждую миграцию нужно применить ко всем схемам, релиз растягивается

Главный риск модели

Рост числа схем замедляет обслуживание и резервное копирование: нужен регламент и автоматизация

Отдельная база данных на каждого клиента

Кому подходит: Enterprise и регулируемые отрасли: клиент требует физического разделения данных и своих сроков обновления
Изоляция данных: Максимальная: у клиента своя база, свои права, свой график обслуживания и своя копия
Стоимость эксплуатации: Высокая: больше соединений, резервных копий, ресурсов и ручных операций
Сложность миграций: Дороже всего: много баз, разные версии схемы, поэтапные релизы по клиентам

Главный риск модели

Эксплуатация становится отдельной работой: без автоматизации развёртывания число баз быстро становится неуправляемым

Общая база для массового сегмента, выделенная — для крупных

Кому подходит: Продукты, которые растут от малого бизнеса к enterprise и не хотят переписывать ядро на каждом этапе
Изоляция данных: По сегменту: массовые клиенты в общей базе, крупные и требовательные — на выделенной
Стоимость эксплуатации: Оптимальная при росте: инфраструктура масштабируется вместе с выручкой, а не заранее
Сложность миграций: Самая сложная: поддерживаются две модели, значит две ветки миграций и два набора тестов

Главный риск модели

Двойная поддержка окупается только на объёме; для маленького продукта это лишняя сложность

О том, как продукт масштабируется вместе с портфелем клиентов, — в статье Архитектура масштабирования SaaS.

Сравнение моделей мультитенантности
Критерий	Общая база	Схема на клиента	База на клиента	Гибрид
Изоляция данных	Логическая	Средняя	Максимальная	По сегменту
Стоимость инфраструктуры на клиента	Низкая	Средняя	Высокая	Растёт вместе с выручкой
Сложность миграций	Низкая	Средняя	Высокая	Высокая
Требования ИБ крупного клиента	Закрываются не всегда	Обычно закрываются	Закрываются	Закрываются
Кому подходит	Тысячи мелких аккаунтов	Сотни B2B-клиентов	Enterprise	Смешанный портфель

Что должно уметь SaaS-продукт

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

Деньги: тарифы, подписки, счета

Тарифы и лимиты

Планы, лимиты по пользователям, объектам и объёму, разовые дополнения. Правила перехода между тарифами описываются заранее, а не «допишем, когда начнём продавать».

Пробный период

Триал с ограничением по времени или по объёму, напоминания о завершении и автоматический перевод в платный режим без ручных действий менеджера.

Рекуррентные платежи

Списание по расписанию, повторные попытки при отказе, обновление карты, счёт для оплаты по реквизитам и сверка поступлений с подписками.

Счета, акты и налоги

Автоматическое формирование документов, закрывающие акты за период, работа с НДС и разными системами налогообложения.

Usage-based и гибрид

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

Proration и апгрейды

Пересчёт стоимости при смене тарифа и докупке мест в середине периода: это та часть, где чаще всего теряются деньги и доверие клиента.

Кто и что может внутри клиента

Аккаунт, команда, роли

Организация, приглашение сотрудников, роли и права. Для B2B это обязательная часть: клиент приводит свою команду, а не одного пользователя.

Онбординг

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

SSO и корпоративный вход

Вход через корпоративный каталог, двухфакторная аутентификация, ограничение по IP и доменам, управление активными сессиями.

Тарифные ограничения

Права и лимиты зависят от оплаченного плана: функция недоступна не потому, что «забыли показать», а потому что не входит в тариф — и это видно пользователю.

Журнал действий

Кто, когда и что изменил: для корпоративных клиентов наличие журнала часто является условием покупки.

Передача и удаление данных

Экспорт данных клиента и корректное удаление при расторжении — требование, которое лучше заложить сразу, а не собирать вручную.

То, за что клиент платит

Ядро продукта

Основной сценарий, ради которого покупают: он проектируется первым и доводится до конца пути, а не до «демо-экрана».

Рабочее место и отчёты

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

Настройка без разработчика

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

Уведомления и коммуникации

Почта, мессенджеры, push внутри продукта: события, эскалации и напоминания по сценариям, а не общая рассылка.

API и вебхуки

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

Импорт и экспорт

Загрузка данных из Excel и чужих систем, выгрузка в привычные форматы — без этого клиент не перейдёт с текущего инструмента.

Управление продуктом со стороны вендора

Панель вендора

Аккаунты, тарифы, подписки, платежи, блокировки и продления: поддержка должна решать вопрос без выгрузки из базы.

Импersonation под контролем

Вход в аккаунт клиента для разбора обращения — с записью в журнал и уведомлением, а не «попросите пароль».

Метрики продукта

Активные аккаунты, использование функций, конверсия триала, отток по тарифам. Без этих данных развитие идёт вслепую.

Работа с отказами платежей

Очередь просроченных подписок, сценарии напоминаний, отчёт по причинам отказов — самый быстрый способ вернуть выручку.

Поддержка и обращения

Очередь тикетов, привязка к аккаунту, история переписки и база знаний внутри продукта.

Мониторинг и релизы

Метрики, ошибки, трассировка, флаги функций и возможность откатить релиз без остановки сервиса.

Биллинг: от пробного периода до расторжения

Подписка — это не «кнопка оплаты», а жизненный цикл с состояними, документами и отказами платежей. Именно здесь чаще всего теряется выручка: клиент хотел заплатить, но списание не прошло, а напоминание не пришло.

Шаг 01
Триал

Ограниченный доступ, напоминания, подсказки по первому результату
Шаг 02
Активна

Списание по расписанию, счёт и закрывающие документы, уведомления о лимитах
Шаг 03
Просрочка

Повторные попытки, письма, мягкое ограничение функций вместо мгновенной блокировки
Шаг 04
Приостановка

Данные сохраняются, доступ ограничен, клиент может вернуться самостоятельной оплатой
Шаг 05
Возврат

Восстановление доступа, пересчёт периода, история платежей не теряется
Шаг 06
Расторжение

Экспорт данных, финальные документы, удаление по регламенту и срокам хранения

Карты и рекуррент

Списание по расписанию, обновление карты, отказ банка и повторные попытки

СБП и QR

Оплата по QR, сверка поступлений, привязка платежа к подписке, а не «к сумме на счёте»

Счёт по реквизитам

Для корпоративных клиентов: выставление, контроль оплаты, частичные платежи

Валюты и курсы

Мультивалютные тарифы, фиксация курса на период, корректные документы

НДС и системы налогообложения

Разные ставки и режимы, корректные суммы в документах, выгрузка для бухгалтерии

Возвраты и корректировки

Сторно, перерасчёт периода, отражение в документах и отчётности

Устройство биллинга и подписок разобрано подробнее: биллинговая система для SaaS и управление подписками. Готовый пакет первой версии — SaaS-MVP от 449 000 ₽.

Слои платформы

Помимо экранов и функций у продукта есть слои, которые определяют, сколько он стоит в эксплуатации и насколько дорого его менять. Разделяем их сразу: логика не зависит от интерфейса, биллинг — от продукта, интеграции не размазаны по коду.

Слой 1
Клиентская часть

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

Единая точка входа: версионированный API, токены и сессии, ограничение частоты, журнал вызовов, вебхуки наружу.
Слой 3
Домен продукта

Бизнес-логика и правила тарифов, лимиты, статусные модели, расчёты. Логика не зависит от интерфейса и переиспользуется в API, фоне и заданиях.
Слой 4
Биллинг и события

Подписки, платежи, документы, повторные попытки, шина событий между продуктом и биллингом. Ошибка платежа не должна ломать работу продукта.
Слой 5
Данные и изоляция

Схема под выбранную модель мультитенантности, ограничения доступа на уровне модели, партиционирование и история изменений.
Слой 6
Инфраструктура и наблюдаемость

Окружения, автоматическое развёртывание, очереди, кэш, метрики, ошибки, резервные копии и проверенное восстановление.

Как это масштабируется по мере роста портфеля клиентов — в статье Архитектура масштабирования SaaS.

Безопасность и требования клиентов

В SaaS вы отвечаете за данные чужих компаний, а не только за свои. Часть требований приходит от клиентов ещё до покупки — их дешевле учесть в архитектуре, чем закрывать потом под давлением сделки.

Изоляция данных клиентов

Выбранная модель мультитенантности, ограничения на уровне модели и тесты, которые проверяют, что клиент не видит чужие данные. Это тестируется автоматически, а не «мы аккуратно пишем запросы».

152-ФЗ и персональные данные

Состав данных, согласия, сроки хранения, обезличивание в аналитике, регламент удаления по требованию субъекта.

Доступы и журналирование

Роли, права, журнал действий, ограничение доступа сотрудников вендора к данным клиента и фиксация каждого такого входа.

Платежная безопасность

Данные карт не хранятся в вашем контуре: используются платёжные провайдеры и токенизация. Область PCI DSS не расширяется без необходимости.

Резервные копии и восстановление

Регламент копий, проверка восстановления на отдельном стенде, целевое время простоя и потери данных.

Разделение окружений

Тестовые данные не берутся из продакшена «как есть», доступ к продакшену ограничен и логируется.

Полный разбор темы — Безопасность и комплаенс SaaS.

Объём первой версии

Первая версия должна доводить клиента до результата и одновременно позволять брать деньги. Всё остальное — следующими итерациями, по данным об использовании.

Входит в первую версию

Регистрация, вход, восстановление доступа и приглашение команды
Мультитенантность в выбранной модели и ограничения доступа
Один тариф продажи плюс лимиты, переход между планами и пробный период
Рекуррентные платежи с повторными попытками и сверкой поступлений
Ключевой сценарий продукта целиком: от входа до результата
Рабочее место: списки, фильтры, карточки, поиск, экспорт
Админка: аккаунты, тарифы, подписки, справочники, блокировки
Уведомления по событиям: почта и уведомления внутри продукта
API и вебхуки для интеграций клиента
Метрики продукта: активные аккаунты, использование, конверсия триала

Откладываем осознанно

Usage-based биллинг по нескольким метрикам потребления
Мультивалютность и тарифы по регионам
SSO корпоративного клиента и расширенное управление сессиями
Публичный API с лимитами и партнёрской программой
Мобильные приложения для ключевых сценариев
Маркетплейс интеграций и настраиваемые поля
A/B-тесты, флаги функций и удалённая настройка
Выделенный контур для enterprise-клиентов

Когда SaaS-разработка не нужна

Продукт уже полностью закрыт готовой платформой и доработки не требуются
Нет повторяющейся подписки: продукт покупают один раз
Нет ни одной гипотезы о клиенте и метриках, по которым её проверять
Нет ресурсов на поддержку сервиса после запуска: SaaS — это эксплуатация, а не релиз

Репозиторий, инфраструктура и платёжные аккаунты у подрядчика — развитие и продажа продукта тормозятся.

Что делаем

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

Как идёт работа

01
Разбор продукта и метрик

Кто клиент, за что платит, какие метрики считаем признаком работающего продукта.
02
Модель данных и мультитенантность

Выбор модели изоляции с обоснованием по стоимости, требованиям ИБ и планам роста.
03
Тарифы и биллинг

Планы, лимиты, пробный период, рекуррентные платежи, документы — до разработки экранов.
04
Смета и срок

Фиксированный объём первой версии, стоимость и график — до первой строки кода.
05
Итерации

Каждые 1–2 недели — работающая версия на тестовом стенде, а не отчёт о занятости команды.
06
Запуск и первые клиенты

Пилотные аккаунты, онбординг, поддержка первых продаж и разбор узких мест по факту.
07
Развитие по метрикам

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

Типы SaaS-продуктов

API, мобильные, десктопные, гибридные, low-code и no-code продукты.

Ориентиры по стоимости

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

SaaS-MVP

от 449 000 ₽

ориентир 6–10 недель

Первая версия продукта с подписками и мультитенантностью — запустить продажи и проверить гипотезу.

Мультитенантная архитектура в выбранной модели
Тарифы, пробный период, лимиты
Подписки и приём платежей
Личный кабинет и админка
API для интеграций
Мониторинг и резервное копирование

Открыть опубликованный пакет

Чаще всего выбирают

Продуктовая разработка

от 1 200 000 ₽

ориентир 3–5 месяцев

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

Всё из SaaS-MVP
Продуктовые модули и рабочие места
Usage-based и гибридная монетизация
Роли, права, журнал действий
Интеграции с учётными системами клиентов
Метрики продукта и отчётность

Платформа

от 2 500 000 ₽

ориентир от 5 месяцев

Мультитенантная платформа с разделением по требованиям ИБ и выделенными контурами.

Выделенные контуры для крупных клиентов
SSO, 2FA, ограничения по IP и доменам
Шина событий и вебхуки
Экспорт и удаление данных клиента
Нагрузочное тестирование
Регламенты эксплуатации и SLA

Сопровождение и развитие

по SLA

ежемесячно

Эксплуатация сервиса и развитие по метрикам: релизы, мониторинг, поддержка первых клиентов.

Мониторинг, инциденты, реакция по SLA
Обновления и патчи безопасности
Доработки по данным об использовании
Разбор оттока и причин отказов платежей
Оптимизация стоимости инфраструктуры
Консультации по росту продукта

В стоимость входят проектирование, разработка, интеграции, развёртывание, обучение и документация. Исходный код и доступы передаются вам. Дополнительные варианты сотрудничества — в пакетах для бизнеса, примеры реализованных систем — в портфолио.

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

Сколько стоит разработка SaaS?

Нижняя граница — от 449 000 ₽ за первую версию с подписками и мультитенантностью: это опубликованный пакет SaaS-MVP. Дальше стоимость определяется тремя факторами: числом продуктовых модулей, сложностью монетизации (usage-based и гибридные схемы дороже фиксированных тарифов) и требованиями к изоляции данных. Платформа с выделенными контурами для крупных клиентов считается отдельно. Точную смету фиксируем после разбора продукта, до первой строки кода.

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

Общая база с идентификатором клиента — самый дешёвый вариант и подходит массовым продуктам с тысячами небольших аккаунтов, но требует жёсткой дисциплины в ограничениях доступа. Схема или база на клиента дают более сильную изоляцию и закрывают требования службы безопасности крупных заказчиков, но дороже в эксплуатации и сложнее в миграциях. Гибрид — общая база для массового сегмента и выделенная для крупных клиентов — обычно оптимален для продукта, который растёт от малого бизнеса к enterprise. Выбор делаем на втором этапе проекта с расчётом стоимости владения, а не по привычке.

Мы уже сделали MVP — можно ли подключить вас к существующему продукту?

Да, это частая ситуация. Начинаем с технического аудита: смотрим модель данных и изоляцию клиентов, состояние биллинга, узкие места производительности, тестовое покрытие и регламенты эксплуатации. По результатам предлагаем план: что исправить до развития функций, что можно оставить и как организовать работы. Иногда честный вывод — что продукт проще развивать на текущем стеке, и тогда мы работаем в нём, а не переписываем ради технологий.

Как вы считаете метрики и что предлагаете считать?

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

Что с приёмом платежей и документами?

Подключаем платёжных провайдеров (карты и рекуррентные списания, СБП, счёт по реквизитам для юридических лиц), настраиваем повторные попытки при отказе, сверку поступлений с подписками и автоматическое формирование счетов и закрывающих документов. Данные карт в вашем контуре не хранятся — используются токенизация и провайдер, поэтому область PCI DSS не расширяется без необходимости. Зарубежные и российские провайдеры подключаются параллельно, если продукт продаётся в нескольких странах.

Как обеспечивается изоляция данных клиентов?

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

Что происходит после запуска?

Сервис требует эксплуатации: релизы, мониторинг, инциденты, обновления безопасности, резервные копии с проверкой восстановления. Мы работаем по регламенту SLA — срок реакции зависит от критичности, а не от того, кто громче написал. Отдельно разбираем метрики раз в месяц: где отток, какие функции не используют, где отваливается пробный период, что стоит оптимизировать по стоимости инфраструктуры.

Кому принадлежат код, инфраструктура и аккаунты?

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

Можно ли начать с малого и не переписывать потом?

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

У нас нет технического специалиста в команде — это проблема?

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

Разберём ваш продукт

Расскажите, кто ваш клиент, за что он платит и что уже сделано. Предложим модель мультитенантности, состав первой версии и план работ со сроком и стоимостью — до договора и без обязательств.

Телефон: +7 (495) 368-39-51
Что будет после заявки: Свяжемся, разберём продукт и метрики, после чего пришлём модель изоляции данных, состав первой версии, срок и стоимость.
Если продукт уже есть: Посмотрим текущую архитектуру и биллинг и скажем, что менять до развития функций, а что можно оставить.

Полезное рядом: разработка ERP, разработка CRM, мобильные приложения.

Заявка на разбор продукта

Опишите продукт, клиента и текущее состояние — вернёмся с моделью изоляции данных, составом первой версии, сроком и стоимостью.

Ответ 15 мин

Имя *

Телефон *

Сайт или номер кабинета

E-mail

Бюджет на рекламу

Задача

Согласен на обработку персональных данных в соответствии с условиями использования.

Не передаём данные третьим лицам и не звоним с рекламой.

Нужна помощь?

Разработка и развитие SaaS-продуктов: архитектура, биллинг и метрики

Экономика продукта до разработки

Мультитенантность: четыре модели и их цена

Общая база и tenant_id в каждой таблице

Отдельная схема в общей базе на каждого клиента

Отдельная база данных на каждого клиента

Общая база для массового сегмента, выделенная — для крупных

Что должно уметь SaaS-продукт

Деньги: тарифы, подписки, счета

Тарифы и лимиты

Пробный период

Рекуррентные платежи

Счета, акты и налоги

Usage-based и гибрид

Proration и апгрейды

Кто и что может внутри клиента

Аккаунт, команда, роли

Онбординг

SSO и корпоративный вход

Тарифные ограничения

Журнал действий

Передача и удаление данных

То, за что клиент платит

Ядро продукта

Рабочее место и отчёты

Настройка без разработчика

Уведомления и коммуникации

API и вебхуки

Импорт и экспорт

Управление продуктом со стороны вендора

Панель вендора

Импersonation под контролем

Метрики продукта

Работа с отказами платежей

Поддержка и обращения

Мониторинг и релизы

Биллинг: от пробного периода до расторжения

Триал

Активна

Просрочка

Приостановка

Возврат

Расторжение

Карты и рекуррент

СБП и QR

Счёт по реквизитам

Валюты и курсы

НДС и системы налогообложения

Возвраты и корректировки

Слои платформы

Клиентская часть

API-шлюз

Домен продукта

Биллинг и события

Данные и изоляция

Инфраструктура и наблюдаемость

Безопасность и требования клиентов

Изоляция данных клиентов

152-ФЗ и персональные данные

Доступы и журналирование

Платежная безопасность

Резервные копии и восстановление

Разделение окружений

Объём первой версии

Входит в первую версию

Откладываем осознанно

Когда SaaS-разработка не нужна

Риски, из-за которых SaaS не доезжает до выручки

Начали с экранов, а не с модели данных

Биллинг «допишем позже»

Считали деньги по выручке, а не по метрикам

Один клиент стал половиной выручки

Нет регламента эксплуатации

Продукт без владельца кода

Как идёт работа

Разбор продукта и метрик

Модель данных и мультитенантность

Тарифы и биллинг

Смета и срок