Как разработать SaaS с нуля: этапы, MVP и типичные ошибки

Разрабатывать SaaS с нуля стоит в таком порядке: сначала проверить, что за сервис заплатят, затем записать состав первой версии на обследовании, собрать MVP на одном сценарии, подключить на нём одного-двух первых клиентов и только после этого выводить в эксплуатацию и расти. Код пишется не на первом шаге, а на третьем, и до него записываются решения, которые в готовой платформе менять дорого: модель изоляции данных клиентов и размещение.

Сколько всё это стоит, разобрано в статье «Сколько стоит разработка SaaS-платформы», как делить данные клиентов — в статье про мультиарендность, из чего состоит платформа — на странице «Разработка SaaS-платформы».

Пять шагов от идеи до платящих клиентов

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

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

Здесь «шаг» — часть пути от идеи к клиентам, «ступень» — позиция на странице «Тарифы», «этап» — часть работ со своей приёмкой (в выводе в эксплуатацию 300 000–700 000 ₽).

Шаг 1. Проверка спроса до кода

Цель — убедиться, что у проблемы есть платящий клиент, прежде чем строить систему. Код для этого не нужен. Что работает:

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

Пять вопросов для разговора с клиентом

1. Как вы решаете эту задачу сейчас и сколько времени она занимает?
2. Что вы уже пробовали и почему отказались?
3. Кто у вас решает о покупке, а кто будет пользоваться?
4. Какие требования у вас к хранению данных и к безопасности?
5. Что должно произойти, чтобы вы начали пользоваться сервисом в ближайший месяц?

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

Что считать сигналом, а что нет

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

Шаг 2. Обследование: что фиксируем до первой строки кода

Обследование превращает идею в документ, по которому можно разрабатывать и сравнивать предложения. Оно стоит 200 000 ₽ за один-два процесса (2–3 недели) и 350 000 ₽, если платформа связана с несколькими системами (3–4 недели). Здесь фиксируются пять вещей, которые лучше записать до первой строки кода. Дороже всего потом менять вторую, модель изоляции, и пятую, размещение:

1. Кто клиент и какой главный сценарий. Один сценарий, ради которого платят.
2. Модель изоляции данных клиентов. Общая схема, схема на клиента или база на клиента; выбор записывается с причиной и способом перехода, см. статью про мультиарендность.
3. Права. Какие роли в первой версии, какие позже.
4. Тарифная гипотеза. Чем измеряется использование: места, объекты, обращения. На этом шаге достаточно гипотезы, а не кода.
5. Размещение. Где стоят серверы и кто их обслуживает. Ответ зависит от клиентов из четвёртого вопроса первого шага: персональные данные граждан России обычно должны храниться на серверах в России, а клиентам с закрытым контуром может понадобиться отдельное развёртывание.

К ним добавляется список «входит в MVP / откладываем», подписанный сторонами. Он защищает от расширения объёма на ходу.

Шаг 3. MVP: в каком порядке собирать

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

1. Организации, вход и разделение данных. Идентификатор клиента появляется в таблицах и в коде доступа с первого дня, условие по клиенту подставляется в одном слое доступа. Для общей схемы в PostgreSQL добавляются политики на уровне строк как второй замок. Добавить изоляцию в готовую платформу — отдельный проект, а не доработка.
2. Права на сервере. Одна-две роли, но проверка на сервере, а не в интерфейсе.
3. Главный сценарий. От входа до результата, на реальных данных, без боковых функций.
4. Журнал действий и минимальная админка. Организации, пользователи, блокировка. Без них первая жалоба клиента превращается в обращение к разработчику.
5. Тариф и счёт. Счёт на первых клиентах можно выставлять вручную, платёжного провайдера подключают, когда нужна онлайн-оплата.
6. Резервные копии и оповещения. Минимум закладывается в MVP до первого клиента, а не после первой потери данных: копия по расписанию, разовая проверка восстановления на чистом сервере и оповещение о недоступности. Регламент регулярных проверок восстановления, нагрузочные испытания и полный мониторинг относятся к выводу в эксплуатацию.

Работа идёт короткими итерациями: раз в две недели рабочая версия на тестовом стенде. Исходный код лежит в вашем репозитории с первого коммита. Ориентир для MVP — вилка 400 000–1 200 000 ₽ и 2–3 месяца. Где в ней окажется ваш проект, зависит от прав, платежей и документов, требований клиентов к безопасности и интеграций; если выбранный состав в неё не помещается, это видно по итогам обследования, и состав сокращается.

Как принимают MVP

Критерии приёмки записывают до начала работ. Для MVP это четыре проверки: главный сценарий пройден на реальных данных от входа до результата; права проверены из-под каждой роли; данные двух тестовых клиентов не пересекаются; копия восстановлена на чистом сервере. Журнал и оповещение о недоступности проверяют по чек-листу ниже перед подключением платящих клиентов в рабочем режиме. На выходе протокол испытаний, по которому видно, что сделано и что осталось.

Чек-лист готовности к запуску

Перед подключением платящих клиентов в рабочем режиме проверьте семь пунктов. Каждый проверяется действием, а не словами «у нас это есть».

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

Шаг 4. Первые платящие клиенты на MVP

Первых клиентов подключают по одному-двум, а не пачкой. Цель — увидеть, как сценарий работает на их данных, и успеть исправить до следующих.

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

Как подключать клиента

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

Первые один-два клиента работают на MVP, это входит в его цену. Вывод в эксплуатацию превращает MVP в систему в ежедневной эксплуатации для всех клиентов: опытная эксплуатация в полном объёме, регламент проверок восстановления, нагрузочные испытания, полный мониторинг, обучение поддержки и передача исходников. Он режется на этапы по 300 000–700 000 ₽, общая сумма от 1 500 000 ₽. Все цены — на странице «Тарифы».

Шаг 5. Рост: что добавлять и в каком порядке

1. Сначала то, что снимает потери клиентов. Журнал обращений показывает, что мешает пользоваться сценарием.
2. Потом то, о чём просят платящие клиенты: настраиваемые роли, публичный API, вебхуки, обмен с их системами.
3. Смена схемы изоляции для отдельных клиентов, если появились требования к отдельной базе. Если заложены пять вещей из статьи про мультиарендность (идентификатор клиента, неповторяющиеся идентификаторы записей, реестр клиентов, единый слой доступа, префикс у файлов и индекса), это отдельный этап переноса, а не переписывание платформы.
4. Функции на основе ИИ после того, как основной сценарий работает: поиск по данным клиента, разбор файлов, черновики. Что окупается и как считать расходы, разобрано в статье «Как добавить ИИ в SaaS-продукт».
5. Повторные нагрузочные испытания перед ростом числа клиентов, а не после первой остановки сервиса. Первые проводятся при выводе в эксплуатацию.

Каждая из этих задач идёт отдельным этапом с собственной приёмкой, чтобы рост не превратился в бесконечный список доработок.

Пять типичных ошибок, которые заканчиваются переделкой

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

Что делаем мы и с чего начать

С какого шага начинать, зависит от того, что у вас уже есть. Спрос не проверен: первый шаг можно пройти без нас, а к обследованию приходить с записями разговоров, списком клиентов, которые готовы платить, и описанием того, что вы делаете руками сейчас: по ним быстрее выбрать главный сценарий. Спрос подтверждён, а состав первой версии не записан: начинайте с обследования, 200 000 ₽ и 2–3 недели за один-два процесса или 350 000 ₽ и 3–4 недели, если платформа связана с несколькими системами. Оно вычитается из первого этапа, если продолжаете с нами. Состав первой версии, схема изоляции и тарифная гипотеза уже записаны: переходите к MVP.

Порядок у нас такой: обследование, при необходимости пилот одного сценария без биллинга (150 000–400 000 ₽, 2–8 недель), MVP, эксплуатация. Наши границы такие: ядро и первая версия, а не платформа за десятки миллионов; без продвижения сервиса и привлечения клиентов; без круглосуточного дежурства. Код лежит в вашем репозитории с первого коммита, поэтому проект можно передать другой команде. Цены и сроки — на странице «Тарифы», описание услуги — на странице «Разработка SaaS-платформы».