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