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

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

• Создание. Новая организация получает настройки по умолчанию, первого администратора и тариф. Если заведение идёт вручную, рост продукта упирается в одного сотрудника.
• Пробный период. Организация работает с ограничениями; по окончании данные ждут решения, а срок их хранения записан в условиях сервиса.
• Приостановка. При неоплате пользователи видят данные, но не создают новое. Отключение без предупреждения бьёт по бизнесу клиента.
• Выгрузка. Клиент вправе забрать свои данные в понятном формате. Это требование из договоров, и сделать его после запуска всегда дороже, чем заложить заранее.
• Удаление. Данные одной организации стираются из базы, файлов, кэша и копий по заранее известному сроку. Для общей схемы это самая трудоёмкая часть, потому что копия базы содержит всех.

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

Правило простое: всё, что отличается у клиентов, но укладывается в известные формы, живёт в данных. Всё, что требует новой логики, живёт в коде и доступно всем или никому. Практически это четыре слоя.

• Флаги возможностей. Раздел включён или выключен для организации и тарифа. Позволяет выпускать новое сначала для двух-трёх клиентов.
• Дополнительные поля и справочники. Клиент добавляет свои поля к заказу или заявке, правит названия статусов. Поля хранятся структурно, по ним работают фильтры и отчёты.
• Шаблоны. Документы, письма и уведомления с подстановкой данных. Шаблон по умолчанию общий, организация может переопределить свой.
• Правила. Порядок согласования, пороги, маршруты. Это уже небольшой язык описания, и его границы стоит ограничить: «если сумма больше порога, то согласует руководитель», а не произвольная программа.

Если клиент платит за то, что в эти слои не укладывается, возможны два пути: функция становится частью продукта и получает флаг, либо это интеграция через API. Третий путь, ветка кода для одного клиента, превращает multi-tenant обратно в набор копий. Мы его не предлагаем.

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

У multi-tenant продукта два круга пользователей: клиенты и ваша команда. Админка для второго круга входит в первую версию. Сотрудник поддержки находит организацию, видит её состояние, лимиты и последние ошибки и при необходимости открывает продукт «от имени клиента». Каждый такой вход пишется в журнал с указанием сотрудника и причины, права на него выдаются отдельной ролью.

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

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

Если клиенты и партнёры смотрят на вашу информацию и оформляют заявки, это личный кабинет или B2B-портал: одна организация-владелец, много внешних пользователей. Если вы продаёте доступ к продукту компаниям, у каждой из которых свои пользователи, настройки, тариф и данные, нужен multi-tenant SaaS.

Общее описание платформы и состав MVP — на странице разработки SaaS-платформы; как сузить первую версию до главного сценария, — на странице разработки SaaS MVP. Устройство такой системы показывает разбор типовой задачи многоарендная B2B SaaS-платформа. Про ИИ-функции в продукте — отдельная статья.