Стоимость начинается с границ первой версии
У SaaS нет одной цены за «сервис с личным кабинетом». За этой фразой могут стоять профиль и список заявок, а могут — отдельные пространства компаний, права сотрудников, подписки, документы и обмен с внешними системами. Чтобы сравнивать предложения разработчиков, сначала нужно описать одинаковый результат.
В Goose Expert стоимость рассчитывается под состав проекта; утверждённых публичных расценок на разработку пока нет. Ниже — пример того, как описать первую версию и разложить её на работы для оценки. Это условная задача, а не клиентский кейс или готовый тариф.
Пример: SaaS для согласования заявок
Представим сервис для компаний, в котором сотрудник отправляет заявку на закупку, а руководитель принимает решение. Результат первой версии: заявку можно провести от создания до решения внутри сервиса, не теряя автора, ответственного и историю.
| Сценарий | Включаем в пример | Оцениваем отдельно, если нужно |
|---|---|---|
| Компания и доступ | Администратор приглашает сотрудников; каждая компания видит только свои заявки. | Самостоятельная регистрация компаний, единый корпоративный вход, особые роли для филиалов. |
| Создание заявки | Сотрудник указывает предмет закупки, сумму и пояснение, затем отправляет заявку руководителю. | Справочник товаров, прикрепление документов, несколько валют. |
| Решение | Один согласующий принимает или отклоняет заявку с комментарием; действие сохраняется в истории. | Цепочки согласования, замещение сотрудника, правила по сумме и отделу. |
| Уведомления | Письмо о новой заявке и о принятом решении. | Мессенджеры, напоминания по расписанию, настройка уведомлений пользователем. |
| Доступ к сервису | Подключение первых компаний вручную по согласованной процедуре. | Онлайн-оплата, пробный период, автоматическое продление и смена тарифа. |
Такой список позволяет обсуждать не абстрактную «платформу», а конкретный путь пользователя. При этом «отдельно» не означает «никогда»: если без онлайн-оплаты нельзя проверить продажи, она становится частью первой версии и попадает в расчёт сразу.
Что сильнее всего меняет оценку
Правила доступа. Недостаточно скрыть чужую заявку в списке: пользователь не должен получить её по прямой ссылке, через выгрузку или запрос к системе. Разделение данных компаний нужно учитывать в разработке и проверках.
Исключения из обычного сценария. Кто согласует заявку, если руководитель уволился? Можно ли изменить её после решения? Что увидит автор при повторной отправке? Эти ответы определяют объём логики и интерфейса.
Подписки и интеграции. Кнопка оплаты — только начало сценария. Понадобится определить поведение при отказе платежа, повторном уведомлении от платёжной системы, смене плана и прекращении доступа. Для каждой интеграции нужны документация, тестовый доступ и правила работы при ошибках.
Нагрузка и размещение. Число зарегистрированных пользователей само по себе мало что говорит. Для оценки полезнее знать, сколько людей работают одновременно, какие операции выполняют и какие объёмы данных обрабатывают. Требования к резервным копиям и восстановлению тоже следует записать заранее.
Как должна выглядеть смета на разработку SaaS
В смете удобнее видеть отдельные работы и проверяемый результат каждой. Пример структуры ниже не содержит ставок и часов: их заполняют после уточнения требований. Несколько ролей может выполнять один специалист — важно понимать, какая работа учтена.
| Работа и роль | Единица для оценки | Что должно быть на выходе |
|---|---|---|
| Разбор задачи · аналитик | Сценарий и его исключения | Согласованные роли, правила и границы первой версии. |
| Интерфейс · дизайнер | Экран со всеми состояниями | Макеты обычной работы, ошибок, пустого списка и отсутствия доступа. |
| Реализация · разработчик | Законченный пользовательский сценарий | Работающий путь от действия пользователя до сохранённого результата. |
| Обмен данными · разработчик | Конкретная интеграция | Оговорённые данные, обработка ошибок и защита от повторной операции. |
| Проверка · тестировщик | Набор проверок сценария | Проверены результат, роли, исключения и поддерживаемые устройства. |
| Запуск · инженер | Окружение и процедура выпуска | Развёртывание, резервное копирование и порядок восстановления в согласованном объёме. |
При оплате по времени стоимость работ складывается из трудоёмкости и ставок специалистов. При фиксированной цене нужно зафиксировать объём, условия приёмки и порядок согласования изменений. В обоих случаях отдельно перечисляют платные внешние сервисы и расходы на инфраструктуру.
Если документации интеграции ещё нет или правила процесса неизвестны, это должно быть видно в оценке. Разумный следующий шаг — ограниченный этап исследования с конкретным результатом, после которого можно уточнить бюджет разработки.
Как принять первую версию
Для условного сервиса из примера проверка может выглядеть так: сотрудник создаёт заявку, руководитель получает уведомление и принимает решение, автор видит результат и историю. Сотрудник другой компании не видит эту заявку даже по прямому адресу. Повторное нажатие на отправку не создаёт дубликат.
Эти условия стоит включить в задачу до оценки. Тогда понятно, что означает «готово» и какие проверки нельзя убрать из бюджета ради меньшей суммы.
Что оплачивается после запуска
Работающий SaaS требует размещения, резервных копий, доставки писем и обслуживания. Платёжные комиссии и стоимость внешних API зависят от выбранных поставщиков и использования. Поддержка, исправления, обновления и новые функции должны иметь понятные условия: не стоит автоматически считать их включёнными в цену первой версии.
Для планирования разделите разовый бюджет запуска, регулярные расходы и затраты, которые растут с нагрузкой. Укажите, кто следит за работой сервиса, реагирует на сбои и оплачивает внешние инструменты.
Что отправить команде для предварительной оценки
- Кто пользуется сервисом, какую задачу решает и как выполняет её сейчас.
- Один полный сценарий первой версии с примером входных данных и результата.
- Роли, разделение компаний и способ предоставления доступа.
- Нужна ли оплата внутри продукта и какие интеграции обязательны.
- Ожидаемая нагрузка, требования к размещению и важная дата запуска.
- Ограничение бюджета, если оно есть: это помогает выбирать объём первой версии.
Пароли, доступы к рабочим системам и персональные данные для первого обращения не нужны. Можно прислать описание процесса или обезличенный пример через форму на странице разработки SaaS на заказ. Если система предназначена только для сотрудников одной компании, пригодится также разбор оценки собственной CRM.