Разработка

SaaS с нуля: что входит в первый релиз

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

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

Минимальный полезный продукт — это один сквозной сценарий

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

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

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

Регистрация, аккаунты и роли

Здесь чаще всего экономят неудачно. В SaaS пользователь почти никогда не один: у клиента есть компания, в ней несколько человек, у них разные права.

Что стоит заложить сразу, даже если кажется избыточным:

  • Разделение «аккаунт компании» и «пользователь». Переделать это позже — значит переписать модель данных и все запросы. Даже если на старте в каждой компании один человек, сущность организации должна существовать.
  • Приглашение коллег по почте. Без этого продукт не растёт внутри клиента, а именно так SaaS обычно и растёт.
  • Хотя бы две роли: владелец и участник. Детальную систему прав можно отложить, но право удалять данные и менять тариф должно быть не у всех.
  • Восстановление пароля и смена почты. Скучно, но без этого поддержка начинает делать это руками в базе.

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

Тарифы, пробный период, биллинг

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

Ключевой вопрос: за что считаем деньги. Вариантов немного, и они по-разному ложатся на продукт.

  1. За пользователя. Проще всего считать, понятно клиенту, но наказывает за приглашение коллег — а именно это вам и нужно.
  2. За объём. Количество записей, проектов, обращений. Требует счётчиков в продукте с первого дня: досчитать задним числом нельзя.
  3. За набор возможностей. Тогда в коде появляются проверки доступности функции по тарифу, и их нужно делать в одном месте, а не рассыпать по экранам.

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

Пробный период. Решите заранее, что происходит в последний день. Данные замораживаются и ждут оплаты? Удаляются через какой-то срок? Аккаунт переходит на бесплатный план с урезанными возможностями? Это не мелочь: от ответа зависит логика доступа и письма, которые уходят клиенту. Отсутствие ответа приводит к тому, что просроченные аккаунты живут вечно и отключаются вручную.

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

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

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

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

Практический минимум:

  • У каждой таблицы с клиентскими данными есть идентификатор организации, и он не необязательный.
  • Фильтр по организации ставится не в каждом запросе вручную, а на уровне, ниже которого запрос уйти не может. Ручная дисциплина здесь не работает: рано или поздно один запрос напишут без фильтра.
  • Права проверяются на сервере. Скрытая в интерфейсе кнопка ничего не защищает.
  • Идентификаторы объектов не должны быть последовательными числами: подставить соседнее число в адресе — первое, что делает любопытный пользователь.
  • Файлы, загруженные клиентами, хранятся с тем же разделением, что и записи в базе, и не отдаются по прямой предсказуемой ссылке.

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

Поддержка и обновления как часть продукта

SaaS отличается от заказной разработки тем, что версия у всех одна и она ваша. Это упрощает жизнь и добавляет обязанности.

  • Канал обращений. Почта или чат в интерфейсе. Главное — чтобы обращение попадало туда, где его увидят, и чтобы клиенту было понятно, когда ждать ответа.
  • Наблюдаемость. Логи, оповещения о падениях, отслеживание ошибок. Без этого вы узнаёте о поломке от клиента, причём не от первого столкнувшегося, а от самого терпеливого.
  • Выкладка без простоя. Обновления идут часто, и каждое не должно останавливать работу клиентов. Это требование к архитектуре, а не к расписанию релизов.
  • Резервные копии, которые проверены восстановлением. Копия, из которой ни разу не разворачивали систему, — предположение, а не копия.
  • Заметки об изменениях. Короткий список того, что поменялось. Это дешёвый способ показать, что продукт живёт.

Административная панель для вашей собственной команды тоже относится к первому релизу: найти аккаунт, посмотреть тариф, продлить пробный период, отключить доступ. Без неё каждое обращение превращается в поход в базу данных.

Что безопасно отложить

Откладывать можно всё, что добавляется поверх работающей основы и не требует переделки модели данных:

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

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

Чеклист перед стартом разработки

  1. Сформулирован один сквозной сценарий, который клиент проходит целиком без вашего участия.
  2. Решено, за что берутся деньги, и в продукте есть счётчик этой величины.
  3. Описано поведение в последний день пробного периода и при неуспешной оплате.
  4. Модель данных с самого начала знает про организацию, а не только про пользователя.
  5. Изоляция клиентских данных сделана на уровне доступа к базе, а не дисциплиной разработчика.
  6. Есть внутренняя панель для поддержки и канал, куда пишут клиенты.
  7. Есть резервные копии, и восстановление из них хотя бы раз проверено.

Если по пунктам 1 и 2 ответы расплывчатые, разработку начинать рано: именно они определяют, какие счётчики и ограничения окажутся зашиты в основание продукта. Как мы раскладываем такие проекты по этапам — в разделе SaaS-разработки.