SaaS — это продукт, а не сайт с оплатой
Внешне SaaS-сервис выглядит как личный кабинет с подпиской. Внутри это система, которая одновременно обслуживает десятки и сотни клиентов, у каждого из которых свои сотрудники, свои данные и свои права доступа. Именно это отличает платформу от корпоративного приложения, сделанного под одну компанию.
Разница проявляется в трёх вещах. Во-первых, данные разных клиентов должны быть изолированы — не только в интерфейсе, но и на уровне запросов: ошибка в одном фильтре покажет чужую информацию. Во-вторых, продукт должен подключаться без вашего участия: клиент регистрируется, выбирает тариф, начинает работать. В-третьих, появляется биллинг — регулярные списания, счета, возвраты, смена тарифа в середине периода.
Если эти три вещи не заложены на старте, они не «добавляются позже» — они переделываются. Пересобрать модель данных под мультиарендность после запуска дороже, чем спроектировать её сразу, поэтому архитектуре стоит уделить время до первой строки кода.
Что должно войти в MVP
MVP — не «урезанная версия всего», а один сценарий, который приносит клиенту пользу и позволяет проверить, что за него готовы платить. Для сервиса это чаще всего одна роль и один ключевой процесс.
- Регистрация компании и вход: создание рабочего пространства, приглашение одного-двух сотрудников
- Один основной сценарий: то, ради чего сервис существует, от начала до результата
- Тариф и ограничения: что доступно на базовом уровне, а что требует оплаты
- Способ оплаты: подписка через эквайринг или счёт для юридических лиц
- Админка оператора: список клиентов, статусы, платежи, ручная выдача доступа
- Журнал действий: кто что изменил — без него разбор проблем превращается в гадание
Что можно отложить: сложные роли, тонкую настройку прав, интеграции с внешними системами, отчёты и экспорт, уведомления по всем каналам, мобильную версию, автоматическую смену тарифов. Всё это имеет смысл, когда есть первые клиенты и понятно, чего они действительно не находят.
Признак готового MVP: новый клиент может зарегистрироваться, оплатить и получить результат без вашего участия в переписке. Если на каждом шаге нужен менеджер, это ещё не сервис, а пилот.
Мультиарендность: как разделять данные клиентов
Это первое архитектурное решение, и оно влияет на всё остальное: стоимость хостинга, скорость разработки, сложность обновлений и уровень изоляции. Есть три типовых подхода.
| Подход | Как устроено | Когда подходит |
|---|---|---|
| Общая база, разделение по клиенту | У каждой записи есть идентификатор компании; запросы всегда фильтруются по нему | Большинство SaaS: дешевле в разработке и эксплуатации, обновления одинаковые для всех |
| Отдельная схема на клиента | Одни и те же таблицы, но в изолированных схемах базы | Нужна более строгая изоляция, но клиентов не тысячи |
| Отдельный экземпляр | Свой сервер или контейнер на клиента | Крупные заказчики с требованиями к размещению данных или выделенным мощностям |
Общая база дешевле, но требует дисциплины: фильтрация по клиенту должна быть встроена в слой доступа к данным, а не написана в каждом запросе вручную. Иначе однажды появится экран, где забыли условие, — и это не «мелкий баг», а утечка.
Отдельный экземпляр выглядит надёжно, но усложняет обновления: каждую версию нужно раскатить на все инсталляции. Для старта это почти всегда избыточно; разумнее начать с общей базы и предусмотреть возможность выделить крупного клиента позже.
Тарифы: что тарифицировать
Тариф — это не только цена, но и правила игры, которые вы фиксируете надолго. Ошибка на этом этапе приводит к тому, что клиенты либо платят меньше, чем стоит обслуживание, либо уходят из-за непонятных ограничений.
- По числу пользователей. Понятно клиенту, легко считается, но наказывает за рост команды: компании начинают экономить места вместо того, чтобы пользоваться сервисом активнее.
- По объёму данных или операций. Честнее по нагрузке, но клиенту сложнее прогнозировать расходы.
- По функциям. Хорошо работает, когда разница между уровнями очевидна: базовый сценарий, расширенный, корпоративный.
- Гибрид. Чаще всего лучший вариант: базовый набор функций плюс лимит по ключевому ресурсу.
Практическое правило: тарифицировать стоит то, что реально создаёт нагрузку или ценность, а не то, что проще посчитать. И обязательно предусмотреть переход между тарифами в обе стороны — с перерасчётом и понятным правилом, что происходит с данными при понижении.
Биллинг: где начинаются сложности
Кнопка «Оплатить» — самая простая часть. Сложности начинаются в повторных списаниях и в исключениях, которых всегда больше, чем ожидаешь.
- Подписка с автоматическим продлением и хранением привязки карты
- Обработка неуспешных списаний: повторные попытки, письма, срок действия доступа
- Вебхуки от платёжного провайдера: статус оплаты может прийти дважды или с задержкой
- Возвраты и частичные возвраты, отмена подписки в середине периода
- Счёт и закрывающие документы для юридических лиц
- История платежей в кабинете клиента и в админке оператора
- Идемпотентность: повторная обработка одного события не должна создавать второй платёж или второй месяц доступа
Отдельно продумайте, что видит клиент, если оплата не прошла. Практика: доступ не отключается мгновенно, сначала приходит уведомление и даётся срок на исправление. Резкое отключение из-за сбоя на стороне банка — самая частая причина злых обращений в поддержку.
Для приёма платежей обычно подключается эквайринг конкретного провайдера. Задача серверной части — не доверять статусу из браузера, а сверять его с подтверждением от провайдера и хранить собственный журнал операций. Детали обмена с внешними системами разбираются в материале про интеграции: логика подтверждений и журналов там та же.
Роли, доступ и данные
В SaaS почти всегда есть три уровня ролей: владелец рабочего пространства, сотрудники компании-клиента и вы как оператор сервиса. Первые два уровня относятся к клиенту, третий — к поддержке, и он должен быть ограничен: доступ к данным клиента ради «посмотреть, что не работает» — плохая практика.
- Владелец: управляет подпиской, приглашает сотрудников, видит все данные компании
- Сотрудник: работает в своём сценарии, видит только свои объекты
- Оператор поддержки: видит метаданные и статусы, доступ к содержимому — по регламенту и с журналированием
Права стоит проверять на сервере, а не только прятать кнопки в интерфейсе. Скрытая кнопка не защищает данные: запрос можно отправить напрямую. И то же касается фильтрации по компании клиента: она должна быть частью серверной логики, а не параметром, который приходит из браузера.
Админка оператора и метрики
Сервис без панели управления быстро превращается в ручную работу: подключить клиента, продлить доступ, разобраться с платежом. Минимальный набор для оператора выглядит так.
- Список компаний: тариф, статус подписки, дата регистрации, активность
- Платежи и подписки: история, ручные корректировки, возвраты
- Лимиты и использование: кто приближается к ограничению тарифа
- Журнал действий и ошибок: что происходило у клиента в момент обращения
- Простые метрики: регистрации, активации, отток — без них непонятно, работает ли продукт
Метрики стоит определить до запуска, а не после. «Сколько клиентов зарегистрировалось» — не главное число; важнее, сколько дошло до первого полезного результата и сколько осталось через месяц.
Этапы работы и стоимость
Разработка SaaS идёт этапами, и каждый заканчивается проверяемым результатом. В 7АРТ стартовая цена веб-приложения — от 49 990 ₽ за первый релиз, состав и сроки фиксируются в договоре: платформа с биллингом и мультиарендностью — это не «сайт за фиксированную сумму», а объём, который зависит от сценариев.
- Разбор задачи: кто клиенты, за что они платят, какой сценарий первый
- Прототип: экраны и состояния, включая пустые и ошибочные
- Архитектура: модель данных, изоляция клиентов, роли, границы биллинга
- Разработка: серверная часть, кабинет, админка оператора
- Платёжный контур: подписки, вебхуки, обработка сбоев
- Запуск на инфраструктуре и передача доступов
- Развитие: то, что отложили в MVP
Посмотреть, как выглядит подобный продукт, можно в концепте SaaS-панели управления подписками. Это демонстрационный проект, а не отзыв клиента, но он показывает уровень проработки интерфейса и сценариев.
Ошибки, которые дороже всего обходятся
- Начинать с интерфейса, не описав модель данных: красивые экраны не спасают, если сущности не сходятся
- Игнорировать изоляцию клиентов «пока клиентов мало» — исправлять после запуска страшнее и дороже
- Строить биллинг вручную вместо использования провайдера: поддержка платёжной логики — отдельная компетенция
- Делать тарифы «на глаз», без понимания нагрузки и себестоимости обслуживания
- Запускать без админки оператора и журнала действий: поддержка начинает работать в переписке и таблицах
- Ставить сроки до того, как определён объём первого релиза
Если задача — проверить спрос, а не построить платформу на годы, честнее сделать узкий продукт с ручными операциями внутри и автоматизировать их по мере роста. Это нормальная стратегия, а не «недоделанный SaaS».
С чего начать обсуждение
Для оценки SaaS-платформы нужно ответить на четыре вопроса: кто ваш клиент, какую работу он выполняет в сервисе, за что платит и какие данные хранит. Из этих ответов складывается первый релиз, а дальше — архитектура и порядок цен.
Направление веб-сервисы: личные кабинеты, SaaS и панели управления описывает, что входит в работу, а цены и состав работ дают ориентир по стартовым суммам. Если у вас уже есть описание продукта — покажите его, разберём сценарии и предложим состав первого этапа.