SaaS-проект — разработка продукта для одновременного использования несколькими независимыми клиентами. MVP занимает 3–5 месяцев: 3 недели на ядро и тарифы, 8–9 недель на разработку, 6–8 недель на биллинг, нагрузку, безопасность и пилот. Бюджет начинается от 600 000 рублей.
Тарифы и изоляция данных клиентов закладываются до первой строки кода. Переделать архитектуру тенантов на середине разработки дороже, чем спланировать ее на старте.
Чем SaaS-проект отличается от сайта и внутренней системы
SaaS-проект — продукт, который поставщик держит на своих серверах, а клиенты открывают через браузер или приложение. Один экземпляр приложения обслуживает многих клиентов, данные каждого изолированы, обновления выходят для всех сразу, оплата идет за доступ, а не за копию программы.
Сайт отдает контент читателю. Внутренняя система служит одной компании. SaaS продает один и тот же процесс многим. Для клиента это переход от Capex — разовых вложений в серверы и лицензии — к Opex, регулярным платежам за доступ, и быстрый старт без своей инфраструктуры.
Критерий: если продукт нужен одной компании под ее процесс — это внутренняя система, а не SaaS.
Инфраструктуру для своего SaaS можно арендовать, например Compute Cloud и Object Storage в Yandex Cloud.
Когда свой SaaS оправдан
Свой продукт оправдан, если за ним стоит уникальный алгоритм, доступ к данным, которых нет у других, или узкая экспертиза. Без этого продукт уходит в гонку на понижение цены.
Три вопроса к идее: чем продукт отличается от готовых аналогов, будут ли клиенты платить каждый месяц, выдержит ли ядро рост числа пользователей без переделки.
Чего избегать: запускать копию существующего сервиса без своего преимущества — ее вытеснят ценой.
Недели 1–3 — ядро, тарифы и тенанты
До кода решают три вещи. Какую одну задачу клиента закрывает продукт. Кто платит: владелец бизнеса, руководитель отдела или сам пользователь. Какие роли есть у пользователей внутри одного клиента — администратор, менеджер, рядовой сотрудник.
Итог этапа — не идея, а пять результатов: документ ядра, тарифная сетка, схема тенантов, черновик SLA и состав поддержки. SLA — обещание клиенту по доступности сервиса и срокам ответа на обращения. Даже черновик заставляет заранее решить, кто отвечает клиентам и в какие часы.
Тарифная модель и формула
Модель подписки задают до найма первого разработчика: оплата за месяц или год, за пользователя, за объем операций, градация по функциям и лимитам, решение — будет ли Free-тариф. Каждая из этих развилок меняет и код биллинга, и договор с клиентом. У Free-тарифа тоже есть лимиты: без них бесплатные клиенты занимают ресурсы, за которые платят другие.
Условный пример: число пользователей × цена места × 12 месяцев против разовой лицензии плюс внедрение плюс серверы — так сравнивают подписку и коробочную покупку на бумаге, без реальных цен. Если лимиты тарифа не определены сейчас, биллинг переписывают уже после запуска, а это отдельная итерация разработки.
Архитектура тенантов
Схема словами: клиент заходит через браузер, попадает в приложение, дальше — общий или раздельный слой данных по клиентам, под ним инфраструктура IaaS. Выбирают между общей базой с разметкой по клиенту и раздельными базами для каждого. Общая база проще в обслуживании, раздельные надежнее отделяют данные одного клиента от другого. Менять выбор на живой системе дорого.
На что обратить внимание: если в данных клиентов будут персональные данные, место физического размещения серверов проверяют до выбора подрядчика инфраструктуры, а не после.
Что сделать сейчас: записать одну задачу клиента, ради которой он будет платить каждый месяц. Без нее тарифная сетка и схема тенантов строятся вслепую.
Недели 4–12 — что входит в MVP, что откладывают
В MVP входит шесть вещей: регистрация клиента и создание тенанта, роли и доступы, основной сценарий ядра, базовые отчеты, экспорт данных, API для ключевых интеграций. Каждый пункт закрывает конкретную задачу, без него продукт не готов к пилоту.
Экспорт данных откладывать нельзя: от него зависит доверие клиента и прямой ответ на страх привязки к поставщику.
Если функция нужна одному клиенту и ломает правило «одна версия для всех» — ее не делают в MVP, а переносят в бэклог после пилота.
Список отложенных функций
Продукт в MVP работает «как есть»: гибкость дает API, а не ручные доработки ядра.
Чего избегать: обещать первому крупному клиенту изменения внутри ядра. Так появляется отдельная ветка кода, которую потом поддерживают только ради него.
Что сделать сейчас: разделить бэклог на две колонки — «в MVP» и «после пилота» — и держать эту границу до конца этапа.
Недели 13–20 — биллинг, нагрузка, безопасность, пилот
Биллинг: списания, лимиты, смена тарифа, блокировка при неоплате. Нагрузка пройдена, если с ростом клиентов и пользователей ответы не тормозят, а данные не смешиваются. Шифрование и двухфакторная аутентификация включены; резервная копия рабочая только после тестового восстановления до живых клиентов.
Контур пилота: оферта, политика конфиденциальности, соглашение об обработке персональных данных по 152-ФЗ, для B2B — договор с индивидуальными условиями. Есть персональные данные — серверы в России.
Ориентиры из англоязычной практики, не нормы для РФ: валовая маржа от 75%, LTV к CAC от 3 к 1, окупаемость CAC до 18 месяцев.
Что сделать сейчас: восстановить базу из резервной копии.
24 артефакта приемки SaaS вместо «все работает»
«Все работает» — не результат приемки, а мнение. Каждый пункт из 24 — документ, отчет или включенная настройка, которую можно показать и проверить. Список делится на два блока: продукт с данными и безопасностью, договоры с поддержкой.
На что обратить внимание: приемка — это протокол с датой и подписью, а не устное «проверили, работает». Без протокола нет доказательства, что пункт закрыт.
Продукт, данные и безопасность
Здесь 12 артефактов, которые показывают, что ядро продукта и инфраструктура готовы к живым клиентам:
- •документ продуктового ядра
- •тарифная сетка
- •схема тенантов
- •протокол проверки изоляции данных между клиентами
- •документация API
- •инструкция по экспорту данных
- •регламент резервного копирования
- •протокол тестового восстановления из копии
- •подтверждение шифрования данных
- •включенная двухфакторная аутентификация
- •место размещения серверов
- •отчет о нагрузочной проверке
SaaS — это программное обеспечение, доступ к которому клиент получает через интернет без установки на свое устройство, и каждый пункт списка подтверждает, что доступ к нему стабилен и безопасен, а не работает «пока никто не смотрит».
Биллинг, договоры и поддержка
Вторые 12 артефактов закрывают деньги, право и обязательства перед клиентом: сценарии списаний, лимиты тарифов, переходы между тарифами, SLA, состав поддержки, публичная оферта, политика конфиденциальности, соглашение об обработке персональных данных, договор для B2B, порядок выхода клиента и выдачи его данных, отчет пилота, список известных ограничений продукта. Для B2B-сегмента дополнительно оформляют договор оказания услуг с индивидуальными условиями — общего шаблона тут недостаточно.
Если принимаете чужой SaaS, а не свою разработку, список тот же плюс представительство вендора в России. Если вендор не называет место хранения данных — процессы с персональными данными к нему не подключают, и это не перестраховка, а прямое следствие предыдущих 23 пунктов: без адреса серверов нельзя проверить ни изоляцию, ни резервное копирование.
Валовая маржа SaaS-продукта на этом этапе тоже смотрится: стандартом считается уровень не ниже 75%, и отчет пилота должен показывать, куда движется этот показатель. Что сделать сейчас: запросить у подрядчика SLA и протокол тестового восстановления — без них остальные 22 пункта проверить нечем.
7 причин срыва сроков SaaS-разработки
Как снять каждую причину на неделях 1–3:
- •Архитектура тенантов не решена в начале → схему тенантов фиксируют до первой строки кода.
- •Тарифная модель меняется посреди разработки → тарифную сетку с лимитами утверждает владелец продукта до кода.
- •Кастомизация под первого клиента → доработки уводят в API, а не в ядро.
- •Зависимость от внешних сервисов и подрядчика → для каждой заранее готовят запасной вариант.
- •Биллинг оставлен на конец → сценарии списаний прописывают вместе с ядром.
- •Юридика и 152-ФЗ вспоминаются перед пилотом → оферту и DPA готовят параллельно с кодом.
- •Нет критериев приемки → на старте утверждают 24 артефакта приемки.
Что сделать сейчас: сверить план с этими семью пунктами до старта разработки.
Разработка SaaS-платформы: MVP от 600 000 ₽ за 3–5 месяцев, план по неделям и приемка по артефактам — запросите оценку.
Источники
