Короткий ответ: из чего получается цена
У студий обычно нет одной фиксированной цены на заказную SaaS-платформу: проекты различаются главным действием клиента, числом независимых организаций, правами сотрудников, способом оплаты и обслуживанием. Эти условия сначала описывают, а затем оценивают предварительную сумму в рублях. Для ориентира по составу можно посмотреть предложения Novacom: на 23 сентября 2026 года у MVP указаны один тариф и разделение клиентов на уровне записей, а у Growth добавлены несколько тарифов, роли команды и управление сервисом. Цены обеих версий на странице обозначены «по запросу». Это пример комплектации конкретного исполнителя, а не универсальная рыночная цена.
Для собственной сметы запишите четыре группы работ: главное действие клиента; создание компаний и права людей внутри них; тариф, оплата и доступ; запуск и ежемесячная работа сервиса. Затем решите, что обязательно в первом выпуске. Если компания продаёт доступ по договору и выставляет счёт вручную, автоматическое списание может подождать. А проверка, что один клиент не видит другого, не может ждать: на этой границе держится доверие к сервису.
Почему обычное веб-приложение и SaaS оценивают по-разному
Представьте систему, где одна компания ведёт заявки сотрудников. Ей нужны рабочие экраны, роли и данные. Теперь та же программа продаётся многим компаниям. Каждой нужно создать своё пространство, пригласить своих людей, задать доступ и пользоваться сервисом без помощи разработчика при каждом новом клиенте. Так к рабочему процессу добавляется продуктовая и операционная часть.
Microsoft разделяет SaaS как модель продажи программы и многоклиентность как способ её устройства. Не каждый SaaS обязан делить одну базу между всеми, и не всякая программа для разных подразделений продаётся как SaaS. Для сметы важнее ответить на практический вопрос: кто именно считается отдельным клиентом и где проходит граница его данных? Если нужен сервис только для вашей компании, начните с общего разбора стоимости веб-приложения.
Что мы проверяли на пути подписки в Aegis
В платном сервисе человек должен дойти от интереса до доступа без загадок. В нашем проекте Aegis VPN пользователь знакомится с возможностями, входит, выбирает срок и тариф и затем управляет услугой в кабинете. Если вынести тариф на экран, а способ продлить или найти помощь спрятать, путь оборвётся после оплаты. Для SaaS это лишь часть задачи: компании ещё нужно дать сотрудникам роли и защитить её данные от соседней организации.
Реальный проект 13FOX
Aegis: тариф должен вести к понятному доступу
В Aegis VPN мы связали знакомство с продуктом, вход, выбор тарифа и управление услугой. На экранах кейса виден путь человека: он понимает, за что платит и где потом управляет подпиской. Для SaaS нужен такой же ясный путь и отдельные правила доступа для каждой компании.
На странице Aegis можно проверить экраны пути до подписки. При оценке своей SaaS-платформы попросите исполнителя отдельно показать путь компании: создание пространства, приглашение сотрудника, смену тарифа и остановку доступа. Это разные операции, даже если на макете они выглядят как несколько кнопок.
Три состава первого выпуска
Первый рабочий выпуск для клиентов. Одна полезная операция, регистрация компаний, роли сотрудников, разделение данных, ручное назначение доступа или простой тариф. Администратор сервиса видит, кого подключили и кому помогать. Это не «демо»: клиент должен получить законченный результат и иметь способ обратиться за поддержкой.
Самостоятельная продажа. Клиент создаёт компанию без переписки с менеджером, приглашает коллег, выбирает тариф и оплачивает его. Система сама меняет доступ по проверенному состоянию оплаты, показывает лимиты и историю. Появляются сценарии просрочки, отмены, смены плана и возврата. Их объём зависит от договора с клиентами и возможностей выбранного платёжного провайдера.
Расширенная платформа. Несколько типов компаний, особые роли, тарифы и ограничения, собственные настройки, связи с учётом клиентов и обещания по доступности. Крупный клиент может запросить отдельное размещение или усиленное разделение данных. Microsoft описывает разные модели общего и выделенного размещения: больше изоляции обычно меняет стоимость и способ сопровождения. Выбирать схему стоит по реальным требованиям, а не по самому дорогому названию.
Проверка границы выпуска: назовите одно действие, ради которого клиент вернётся в сервис завтра. Затем запишите, какие функции нужны, чтобы он выполнил его безопасно и получил результат. Всё, что не связано с этим путём, можно оценить следующим этапом.
Какие строки должны быть в смете
Фраза «разработка личного кабинета и оплата» не описывает весь SaaS. Нужно узнать, что команда делает до кода, как проверяет разделение клиентов и кто отвечает за сервис после запуска. Попросите разнести работы на строки ниже; их можно использовать как короткое техническое задание к оценке.
| Блок | Что включить | Что проверить в предложении |
|---|---|---|
| Продукт | Главная операция, экраны, данные, ошибки и проверка результата | Как клиент закончит работу и что будет принято |
| Клиенты и права | Создание организации, приглашения, роли, границы данных и журнал важных действий | Как тестируют запрет доступа к чужой компании |
| Тариф и деньги | Правила плана, лимиты, оплата или счёт, изменение и остановка доступа | Кто задаёт тариф, что происходит при отказе оплаты и отмене |
| Запуск | Настройка среды, перенос нужных данных, проверка, документация и первая поддержка | Что передают заказчику и кто устраняет ошибки первого запуска |
| После запуска | Размещение, резервные копии, наблюдение за сбоями, обновления и помощь клиентам | Что оплачивается регулярно и кому сообщать о проблеме |
Для сравнения возьмите один период, например первый год. Сложите разовую разработку и запуск + регулярное размещение, сервисы и сопровождение. Вносите суммы только из реальных предложений и не считайте одну работу дважды. Если один исполнитель включает платёжную интеграцию, а другой пишет «по отдельной оценке», добавьте её в отдельную строку второго предложения прежде, чем сравнивать итог.
Тариф на экране ещё не означает работающую подписку
Клиент выбрал план и оплатил первый период. Что происходит, если платёж не прошёл или компания хочет перейти на другой тариф? Сервису нужны правила: когда начинается право пользоваться функцией, какие лимиты действуют, кто видит счёт и когда доступ ограничивают. Без них команда вручную отвечает на каждый спорный случай. Даже если первый договор оплачивают обычным счётом, эти правила лучше записать.
Платёжный провайдер решает свою часть задачи. Например, в документации ЮKassa описано повторное списание с сохранённым способом оплаты; периодичность и отключение автоплатежа сервис настраивает сам. Значит, кнопку оплаты нельзя считать готовой подпиской. В смету отдельно включают логику тарифа, проверку подтверждения платежа, возвраты и ручную обработку исключений по выбранной модели продаж.
Например, клиент оплатил доступ по договору. Менеджер отмечает оплату, а система назначает срок и правила доступа. Такой старт сокращает первую версию обработки платежей, но добавляет ответственного за ручное действие. Запишите его, иначе недорогой первый выпуск обернётся постоянной работой в переписке.
Матрица для сравнения двух предложений
Представьте два условных предложения без реальных цен. Вариант А делает первый путь для компаний с ручной выдачей доступа; вариант Б добавляет самостоятельную продажу. Обе команды могли назвать работу «SaaS», но сумма Б будет покрывать другой объём. Впишите фактические ответы подрядчиков в копию таблицы и попросите назвать проверяемый результат каждой строки.
| Проверка | Предложение А | Предложение Б |
|---|---|---|
| Кто отдельный клиент и кто его сотрудники? | Компания создаётся менеджером; одна роль сотрудника | Компания регистрируется сама; владелец приглашает сотрудников |
| Как клиент получает главный результат? | Одна рабочая операция после ручного включения | Та же операция после самостоятельного входа и оплаты |
| Как проверят запрет чужих данных? | Запросите тест двух компаний: в условии не указан | Тест прямой ссылки на чужую запись включён |
| Кто назначает, меняет и отключает тариф? | Менеджер вручную; его труд остаётся после запуска | Сервис меняет доступ по проверенному состоянию оплаты |
| Что входит в запуск и сопровождение? | Запуск описан; поддержку нужно уточнить | Мониторинг и обработка ошибок обозначены отдельно |
| Разработка / запуск / ежемесячно? | Впишите три суммы из сметы и исключения | Впишите те же три суммы и исключения |
В этом примере нельзя выбрать победителя по одной общей цене: у А неясны проверка изоляции и поддержка, у Б шире путь продажи. Попросите обе команды оценить одинаковую первую версию. Затем сравните разовую разработку, запуск и ежемесячные расходы отдельно — без скрытого труда менеджера.
После таблицы остаются три решения, которые должен принять заказчик: кто считается клиентом, по какому правилу продаётся доступ и сколько поддержки обещано. Исполнитель может предложить устройство системы, но не должен угадывать бизнес-условия вместо вас. Если путь состоит только из личных данных одного клиента, дополнительно сравните разработку личного кабинета: объём может быть уже.
Как уменьшить первый бюджет без ловушки для роста
Уберите из первого выпуска дополнительные отчёты, разные варианты брендирования и редкие настройки. Оставьте один вид клиента, один основной путь, понятный тариф и способ помочь человеку при ошибке. Если автоматическая продажа пока не нужна, начните с ручного счёта и запишите владельца этого процесса. После первых клиентов станет видно, какие правила повторяются и стоит ли их автоматизировать.
Сохраняйте то, что позднее опасно «достраивать сбоку»: отдельную запись для каждой компании-клиента, проверку прав на сервере, резервные копии нужных данных и наблюдение за ошибками. Чек-лист Microsoft для многоклиентных решений отдельно требует проверять изоляцию клиентов и учитывать потребление ресурсов. Если перенести эти вопросы на время после первых продаж, оценка первого выпуска станет искусственно ниже, а риски останутся.
Что проверить перед тем, как назвать платформу готовой
Создайте две тестовые компании. В первой владелец приглашает сотрудника; во второй такой же сотрудник работает со своими данными. Затем пройдите пять проверок:
- Рабочий путь. Каждая компания выполняет главное действие и видит свой результат после повторного входа.
- Граница данных. Пользователь первой компании пытается открыть адрес записи второй. Сервер отказывает, а не просто скрывает кнопку в интерфейсе.
- Доступ по тарифу. Администратор меняет план или срок. Система показывает новое правило и объясняет, что будет с уже созданными данными.
- Сбой оплаты или внешнего сервиса. Ошибка записана, ответственному понятно, что повторять; клиент не получает два разных состояния доступа из-за одного события.
- Работа после запуска. Команда умеет восстановить важные данные из резервной копии и получает сообщение о сбое до обращения клиента.
Это пример проверочного сценария, который можно адаптировать под продукт. Зафиксируйте ожидаемый результат и ответственного за каждую проверку прямо в смете. Так на приёмке спор о «готовности» превращается в разговор о наблюдаемой работе сервиса.
Частые вопросы
Сколько стоит разработка SaaS-платформы?
У студий обычно нет одной фиксированной цены на заказную SaaS-платформу. На 23 сентября 2026 года Novacom публикует составы MVP, Growth и Enterprise, но стоимость каждого обозначает «по запросу». Предварительную сумму в рублях готовят после описания рабочего сценария, клиентов, доступа, оплаты и обслуживания. Сравнивайте две оценки только при одинаковом составе.
Чем SaaS отличается от обычного веб-приложения?
SaaS означает, что программу предоставляют клиентам как сервис и отвечают за её работу. При продаже нескольким компаниям обычно добавляются регистрация организации, приглашение сотрудников, разделение данных и правила тарифов. Само по себе веб-приложение может работать только для одной компании и не иметь этих задач.
Можно ли запустить SaaS без автоматического списания?
Да, если модель продаж допускает ручной счёт и подтверждение оплаты на первом этапе. Но кто выдаёт доступ, когда он начинается и заканчивается, как меняется тариф и что видит клиент при просрочке, нужно решить сразу. Иначе ручная работа будет скрытой частью продукта.
Нужна ли отдельная база данных каждому клиенту?
Не всегда. Возможны общие и выделенные ресурсы; выбор зависит от требований клиентов, объёма данных, нагрузки, цены ошибки и стоимости обслуживания. В любом варианте сервер обязан проверять права, а тесты должны включать попытку открыть данные другой организации.
Источники и полезное продолжение
- Novacom: составы SaaS-предложений и цены «по запросу», проверено 23.09.2026.
- Microsoft: различие SaaS и многоклиентной архитектуры.
- Microsoft: чек-лист многоклиентного сервиса.
- ЮKassa: повторные списания и ответственность сервиса за периодичность.
Если ваш продукт пока не продаётся по подписке разным компаниям, начните с общей сметы веб-приложения. Для предметного проектирования многоклиентного сервиса посмотрите наше решение по SaaS-платформе.
Разложим вашу идею SaaS на смету
Оставьте номер для короткого разговора. На нём достаточно словами описать главное действие клиента, типы клиентов, оплату и внешние системы. Мы отделим первый выпуск от следующих этапов и подготовим предварительную оценку по разовым и регулярным работам.
Для первого разговора не нужны пароли и доступы к рабочим системам.