В SaaS MVP включают главный сценарий, ради которого клиент платит, организации с приглашением коллег, одну-две роли, тариф со счётом, минимальную админку для вашей команды и основу, которую трудно переделать позже: разделение данных клиентов, проверку прав на сервере, копии и журнал. Откладывают настраиваемые роли, вход через каталоги клиентов, автоматические списания, публичный API и красивые отчёты.
Разбираем не «что обычно кладут в MVP», а способ принять это решение для вашего продукта: вопрос к каждой функции, три списка и несколько вещей, которые нельзя вычёркивать. Полный путь от идеи до платящих клиентов описан в статье «Как разработать SaaS с нуля», цена по ступеням — в статье «Сколько стоит разработка SaaS-платформы», а услуга описана на странице «Разработка SaaS MVP».
Чем MVP отличается от «плохой первой версии»
MVP — это не урезанный продукт, а эксперимент. У него есть вопрос («заплатят ли небольшие логистические компании за автоматическую сверку актов?»), есть круг участников (первые организации), есть срок и есть заранее записанное правило, что считать ответом. Версия без вопроса — просто маленький продукт, и по ней нельзя понять, продолжать работу или нет.
Поэтому первое действие — не список экранов, а формулировка вопроса. Если не удаётся уложить её в одно предложение, первая версия получится длиннее и дороже, чем нужно. Условный пример формулировки: «Бухгалтеры в небольших торговых компаниях готовы платить по тарифу за сверку актов, если она занимает минуты, а не вечер».
| Что проверяем | Как видно из MVP | Что делаем, если ответ «нет» |
|---|---|---|
| Есть ли проблема | Люди приходят сами и доводят сценарий до конца | Меняем целевую группу или формулировку проблемы, а не добавляем функции |
| Решает ли её сценарий | Пользователи возвращаются и повторяют сценарий | Переделываем сценарий; код ядра остаётся |
| Готовы ли платить | Счета выставлены и оплачены, отказы объяснены | Меняем тариф или аудиторию; если ответ «нет» повторяется, останавливаемся |
| Подходит ли продукт купившим | В списке просьб повторяются одни и те же пункты | Берём в работу повторяющиеся, остальные оставляем в списке |
Пять вопросов к каждой функции
Отбор строится на коротком наборе вопросов. Их задают каждой функции из списка, пока список не превратится в три группы.
- Получит ли первый платящий клиент главный результат без этой функции? Если да, функция не входит в ядро.
- Можно ли сделать это руками для первых десяти организаций? Если да, это ручной режим со строкой «когда автоматизировать».
- Есть ли готовый компонент? Вход, отправка писем, хранение файлов и приём оплаты обычно берутся готовыми.
- Насколько дорого менять это позже? Внешний вид экрана меняется дёшево, схема разделения данных клиентов — дорого.
- Просили ли об этом как об условии покупки? Фраза «было бы здорово» функцию не оправдывает, фраза «без этого не подпишем» — оправдывает, но с вопросом, сколько таких клиентов.
Ответы дают решение. Ниже условный пример для продукта по сверке актов между компаниями, чтобы показать, как работает отбор.
| Функция | Вопросы, которые решают | Решение | Когда вернёмся |
|---|---|---|---|
| Загрузка актов и сверка | Без неё нет ценности | Входит, это главный сценарий | Сразу |
| Организации и приглашение коллег | Без неё нет продукта для компании; менять позже дорого | Входит | Сразу |
| Роли «администратор» и «пользователь» | Этого хватает первым клиентам | Входит; настраиваемые роли откладываем | Клиент просит разграничить доступ внутри команды |
| Счёт и оплата тарифа | Без оплаты не проверить готовность платить | Входит; счёт выставляет бухгалтер по выгрузке | Когда выгрузка занимает рабочий день |
| Вход через корпоративный каталог | Нужен одному-двум крупным клиентам | Откладываем | Крупный клиент ставит условием сделки |
| Публичный API | Первые клиенты работают через интерфейс | Откладываем | Несколько клиентов просят интеграцию |
| Красивый дашборд | Выгрузка в таблицу решает вопрос | Откладываем; отчёт отдаём вручную | Один и тот же отчёт просят у многих |
| Письма-уведомления | Нужно несколько типовых писем | Входит, через готовый почтовый сервис | Сразу |
Что делаем вручную и как это записать
Ручной режим — не небрежность, а способ не писать код под сценарий, который ещё не подтвердился. Он работает, пока каждое действие записано в таблицу с тремя полями: кто делает, сколько времени уходит, при каких условиях автоматизируем. Без третьего поля ручные операции остаются навсегда.
- Заведение организации. Администратор создаёт её в админке по заявке и отправляет приглашение первому пользователю.
- Счета и акты. Тариф записан в системе, бухгалтерия готовит документы по выгрузке.
- Первичная настройка. Менеджер на звонке настраивает справочники клиента, а не клиент по инструкции.
- Отчёты по запросу. Аналитик готовит выгрузку и приписывает вывод; частота запросов подсказывает, какие отчёты нужны всем.
У ручного режима есть предел. Если действие нужно повторять ежедневно и оно ошибочное при спешке, лучше автоматизировать. Если от действия зависит безопасность (выдача прав, удаление данных), оно не делается руками «на глаз»: для него есть роль, подтверждение и запись в журнале.
Что взять готовым, а не писать
Первая версия не должна заново изобретать части, которые не отличают ваш продукт. Но «взять готовое» тоже решение с последствиями: его нужно подключить, проверить и поддерживать.
| Часть | Что берём | Что остаётся вам |
|---|---|---|
| Вход и восстановление доступа | Проверенную библиотеку или сервер входа вроде Keycloak | Правила паролей, двухфакторность для ролей с деньгами |
| Приём оплаты | Платёжного провайдера, подключаемого по документации | Договор с провайдером и кассовая отчётность; данные карт мы не храним |
| Письма | Почтовый сервис | Шаблоны писем и адрес отправителя |
| Файлы | S3-совместимое хранилище | Проверка типа и размера, права доступа к файлам |
| Админка | Каркас приложения с готовыми списками и формами | Права сотрудников, журнал входов «от имени клиента» |
Правило: готовое подключаем за тонким слоем в коде, чтобы можно было заменить провайдера. Это занимает день работы и экономит месяцы, когда провайдер перестанет подходить. Платежи принимает ваш эквайринг, мы подключаем интерфейс, но не принимаем деньги от вашего имени.
Что нельзя откладывать, даже если очень хочется
Есть вещи, которые в первый день стоят немного, а через полгода — очень много. Их вычёркивать нельзя, и в хорошей смете они видны отдельными строками.
| Вещь | Почему дёшево сейчас | Что будет, если отложить |
|---|---|---|
| Разделение данных клиентов | Идентификатор организации и политики в базе закладываются вместе со схемой | Переделка каждой таблицы и запроса; риск, что клиент увидит чужое |
| Права на сервере | Проверка на каждый запрос пишется один раз | Скрытая в интерфейсе кнопка, а адрес запроса открыт |
| Копии и проверка восстановления | Настройка за день и разовая проверка | Первая потеря данных у платящего клиента |
| Журнал действий | Пишется вместе с операциями | Нельзя ответить клиенту, кто и когда изменил данные |
| События для воронки | Несколько строк в коде сценария | MVP запущен, а ответить на главный вопрос нельзя |
| Тест «клиент A не видит клиента B» | Пишется раньше экранов | Узнаёте о дыре от клиента |
| Исходники в вашем репозитории | Работа с первого коммита | Передача подрядчика превращается в переписывание |
Схемы разделения данных разобраны в статье «Мультиарендность в SaaS». Свойства ядра для многих клиентов описаны на странице «Разработка multi-tenant SaaS».
Порядок сборки: вертикальный срез вместо слоёв
Самая частая ошибка порядка работ — сначала «вся база», потом «весь интерфейс», потом «всё вместе». Показать клиенту нечего до последней недели. Надёжнее собирать вертикальными срезами: тонкий кусок от экрана до базы, который уже можно потрогать.
- Каркас. Организации, вход, две роли, развёртывание и сборка; тест изоляции данных. Результат: можно создать организацию и войти.
- Первый срез сценария. Самый короткий путь от начала до результата, пусть с грубым экраном. Результат: один настоящий пользователь проходит сценарий.
- Расширение сценария. Исключения, ошибки, повторный запуск; каждые две недели версия показывается на тестовом стенде.
- Тариф и счёт. Ограничения тарифа, выгрузка для бухгалтерии, админка.
- Проверка перед запуском. Прогон прав из-под каждой роли, восстановление из копии, оповещение о недоступности.
К каждому срезу прикладывается описание принятия: какой случай должен пройти, чтобы срез считался сделанным. Если принять нельзя, срез не закрыт, и новые функции не берутся.
Шесть ошибок при определении объёма
- Список функций без вопроса. Пока не сформулирован вопрос эксперимента, любая функция выглядит нужной.
- «Как у конкурента». Конкурент накапливал функции годами, а ваш MVP повторяет результат, не повторяя историю.
- Настраиваемость на старте. Если не известно, что именно клиенты хотят настроить, настройки делают наугад и после первого клиента переделывают.
- Автоматизация всего. Автоматический счёт и возвраты строятся до того, как кто-то заплатил в первый раз.
- Нет списка «откладываем». Тогда он существует только в голове самого настойчивого участника проекта.
- Нет критериев остановки. Если не записано, при каких результатах вы остановитесь, продолжать будете при любых.
Что делаем мы и с чего начать
Начинаем с обследования: 200 000 ₽ и 2–3 недели за один-два процесса, 350 000 ₽ и 3–4 недели, если нужен обмен с несколькими системами. На выходе формулировка вопроса, три списка объёма, схема данных и изоляции клиентов, критерии успеха и остановки и вилка бюджета. Оплата вычитается из первого этапа, если продолжаете с нами, а документом можно пользоваться без нас.
Дальше, если нужно, идёт пилот одного сценария (150 000–400 000 ₽, 2–8 недель) или сразу MVP: 400 000–1 200 000 ₽ за 2–3 месяца, в тарифах это тяжёлый пилот. После него вывод в эксплуатацию от 1 500 000 ₽ этапами по 300 000–700 000 ₽ и сопровождение от 20 000 ₽ в месяц. Остановиться можно после любой ступени, сделанное остаётся у вас по акту, исходники лежат в вашем репозитории с первого коммита. Мы не ищем клиентов и не продвигаем сервис. Все цены — на странице «Тарифы», описание услуги — на странице «Разработка SaaS MVP».
Частые вопросы
Что входит в MVP SaaS-продукта?
Главный сценарий, организации и приглашение коллег, одна-две роли, тариф со счётом, минимальная админка для вашей команды, события для воронки, копии с проверкой восстановления и оповещение о недоступности. Основа вроде разделения данных клиентов и проверки прав на сервере входит обязательно.
Сколько стоит и сколько занимает MVP?
MVP стоит 400 000–1 200 000 ₽ и занимает 2–3 месяца, в тарифах он идёт как тяжёлый пилот. Перед ним обследование за 200 000 ₽ (350 000 ₽ при нескольких системах), его стоимость вычитается из первого этапа, если продолжаете с нами.
Чем MVP отличается от пилота?
Пилот проверяет, работает ли один сценарий на реальных данных, без подписок и платежей, он стоит 150 000–400 000 ₽ за 2–8 недель. MVP рассчитан на первые организации с тарифом и счётом и проверяет готовность платить.
Можно ли делать MVP без ролей и организаций?
Если продукт для одной компании и продавать доступ вы не планируете, организации не нужны, и это не SaaS, а веб-сервис или кабинет. Если клиентов будет много, организации и разделение данных закладываются сразу, потому что менять их позже дорого.
Как понять, что функцию можно отложить?
Задайте пять вопросов: нужна ли она для главного результата, можно ли сделать руками, есть ли готовый компонент, дорого ли менять позже, просили ли как условие покупки. Если на первый вопрос ответ «нет» и дорого менять не придётся, откладывайте.
Нужно ли подключать оплату в MVP?
Не обязательно. Если первые клиенты платят по счёту, достаточно тарифа в системе и выгрузки для бухгалтерии. Платёжного провайдера подключаем, когда онлайн-оплата нужна для сценария. Договор с провайдером заключаете вы, данные карт у провайдера.
Что делать, если MVP не сработал?
Смотреть на критерии, записанные до запуска. Если не заплатили, меняем аудиторию или тариф; если не возвращаются, переделываем сценарий; если ответ «нет» повторяется, останавливаемся. Остановка по правилу — результат эксперимента, а не провал.
Можно ли потом развить MVP в платформу?
Да, если в нём заложено ядро: организации, права на сервере, тест изоляции данных, журнал. Нагрузочные испытания, регламенты и полный мониторинг добавляются при выводе в эксплуатацию. Исходный код в вашем репозитории, развивать его можно с нами или без нас.