Как оценить стоимость SaaS-разработки: из чего на самом деле складывается бюджет

Сервис для совместного ведения небольшого списка задач и B2B-платформа, в которой сотни компаний управляют сотрудниками, тарифами, документами, интеграциями и миллионами операций, формально относятся к одной категории — Software as a Service.

Технически между ними может быть огромная разница.

Поэтому стоимость SaaS нельзя нормально оценивать по количеству экранов или фразе:

Нам нужен сервис примерно как X, только немного проще.

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

Разберём SaaS на составные части и попробуем понять, где на самом деле появляются основные трудозатраты.

SaaS — это не просто веб-приложение с оплатой

Возьмём обычную внутреннюю систему компании.

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

Теперь превращаем её в SaaS.

Появляется другая структура:

Платформа
│
├── Компания A
│   ├── Владелец
│   ├── Администраторы
│   └── Пользователи
│
├── Компания B
│   ├── Владелец
│   ├── Администраторы
│   └── Пользователи
│
└── Компания C
    ├── Владелец
    ├── Администраторы
    └── Пользователи

Данные компании A не должны случайно оказаться доступны компании B.

Каждая организация может иметь свой тариф.

У каждого тарифа — собственные ограничения.

Количество пользователей меняется.

Подписки начинаются, продлеваются, отменяются и иногда не оплачиваются.

Одним клиентам доступна функция, другим — нет.

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

То есть SaaS — это не только бизнес-функция продукта.

Это ещё и платформа управления множеством независимых клиентов поверх одной системы.

И эта платформенная часть может занимать значительную долю разработки.

Начинать оценку нужно не с функций, а с модели бизнеса

Предположим, планируется сервис управления проектами.

На первый взгляд требования звучат достаточно понятно:

• проекты;
• задачи;
• комментарии;
• файлы;
• уведомления;
• аналитика.

Но перед оценкой необходимо задать другой набор вопросов.

Кто платит: отдельный пользователь или организация?

Можно ли приглашать сотрудников?

Есть ли разные роли?

Что происходит после увольнения сотрудника?

Кому принадлежат созданные им данные?

Можно ли одному человеку состоять сразу в нескольких организациях?

Будет ли бесплатный тариф?

Какие ограничения есть у каждого плана?

Тариф зависит от числа пользователей, объёма данных или количества операций?

Можно ли менять тариф посреди расчётного периода?

Что происходит при неудачном списании?

Сохраняются ли данные после отмены подписки?

Уже эти вопросы способны изменить архитектуру проекта.

Поэтому хороший расчёт SaaS начинается с business model + domain model, а только потом переходит к экранным формам.

Удобная формула для предварительной оценки

На раннем этапе стоимость можно мысленно представить так:

Стоимость SaaS = продуктовая аналитика + UX/UI + основная бизнес-логика + SaaS-платформа + интеграции + QA + безопасность + инфраструктура + управление разработкой + резерв.

Где под SaaS-платформой понимаются вещи, которых может вообще не быть в обычном корпоративном приложении:

Tenant management
User management
Invitations
Roles & permissions
Plans
Subscriptions
Usage limits
Billing
Feature flags
Customer administration
Platform administration
Audit

Если эти компоненты не учитывать при первоначальном расчёте, бюджет почти неизбежно начинает расти уже после старта проекта.

Шаг 1. Отделяем основную ценность продукта от SaaS-обвязки

Представим сервис автоматической подготовки документов.

Главная ценность:

Пользователь вводит данные
        ↓
Система обрабатывает их
        ↓
Формируется документ
        ↓
Пользователь получает результат

Это ядро продукта.

Но коммерческий SaaS вокруг него может выглядеть так:

Регистрация
    ↓
Создание организации
    ↓
Выбор тарифа
    ↓
Оплата
    ↓
Приглашение сотрудников
    ↓
Работа с документами
    ↓
Учёт использованного лимита
    ↓
Продление подписки
    ↓
Счета / уведомления / управление тарифом

Вторая цепочка сама по себе превращается в большой функциональный блок.

Поэтому при оценке важно отдельно считать:

Core Product — то, ради чего клиент покупает сервис.

И:

SaaS Platform Layer — то, что позволяет этот продукт продавать многим клиентам как услугу.

Шаг 2. Определяем tenant-модель

Один из ключевых терминов SaaS — tenant.

Tenant обычно обозначает отдельного клиента системы: компанию, команду, рабочее пространство или организацию.

Например:

Tenant: ООО «Альфа»

Users:
Иван
Анна
Сергей

Projects:
CRM
Интернет-магазин
Внутренний портал

Другой клиент:

Tenant: ООО «Бета»

Users:
Мария
Алексей

Projects:
ERP
Клиентский кабинет

Система обязана гарантировать, что пользователи «Альфы» не получат доступ к данным «Беты».

Звучит очевидно.

Но именно это требование влияет практически на всё приложение.

Multi-tenancy проходит через каждый запрос

Представим обычный запрос:

GET /api/projects/482

Недостаточно проверить, что пользователь авторизован.

Нужно убедиться, что проект принадлежит организации, к которой этот пользователь действительно имеет доступ.

Условно:

User
  ↓
Membership
  ↓
Tenant
  ↓
Project

И только после проверки всей цепочки данные можно вернуть клиенту.

Если tenant isolation реализована неправильно, один клиент потенциально может увидеть информацию другого.

Для SaaS это один из самых неприятных классов архитектурных ошибок.

Поэтому multi-tenancy нельзя бездумно «прикрутить после MVP».

Её модель желательно определить в самом начале.

Как хранить данные нескольких клиентов

Существует несколько вариантов.

Упрощённо их можно представить так.

Общая база и общие таблицы

projects

id
tenant_id
title
...

Все клиенты находятся в одних таблицах, а записи разделяются по tenant_id.

Преимущества:

относительно простая инфраструктура;

удобные миграции;

эффективное использование ресурсов.

Но приложение должно безошибочно применять tenant-фильтрацию.

Отдельные схемы

Условно:

tenant_alpha.projects
tenant_beta.projects
tenant_gamma.projects

Изоляция становится сильнее, но усложняются миграции и эксплуатация.

Отдельная база для каждого клиента

database_alpha
database_beta
database_gamma

Можно получить ещё более сильную изоляцию, но при большом количестве клиентов становится сложнее управлять инфраструктурой.

Нет универсально лучшей модели.

Решение зависит от требований к безопасности, количеству клиентов, объёму данных, стоимости инфраструктуры и особенностей продукта.

Но выбранная стратегия напрямую влияет на бюджет разработки и дальнейшей эксплуатации.

Шаг 3. Модель пользователей часто сложнее, чем кажется

На прототипе всё просто:

User
├── email
├── password
└── role

Затем появляется требование:

Один пользователь должен иметь возможность работать сразу в нескольких компаниях.

Теперь роль нельзя хранить непосредственно у пользователя.

Потому что Иван может быть:

Компания A → OWNER
Компания B → MANAGER
Компания C → VIEWER

Появляется отдельная связь:

User
        ↓
Membership
        ↓
Organization

А внутри Membership уже находятся роль, статус, дата приглашения и другие параметры.

Если такую возможность обнаружить после того, как вокруг старой модели построена половина продукта, изменение затронет множество модулей.

Это хороший пример требования, которое практически не видно на макетах, но сильно влияет на стоимость.

Шаг 4. Роли превращаются в систему разрешений

На старте достаточно:

OWNER
ADMIN
USER

Потом клиент спрашивает:

Можно ли бухгалтеру показывать платежи, но запретить редактировать проекты?

Возникает permission model:

project.read
project.create
project.update
project.delete

billing.read
billing.manage

members.read
members.invite
members.remove

settings.read
settings.manage

Тогда роль становится набором permissions.

Это уже более гибкая система.

Но её нужно проектировать, реализовывать и тестировать.

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

Шаг 5. Тариф — это тоже часть архитектуры

Представим три плана:

На лендинге это простая таблица.

В коде возникает целая система правил.

Например:

canCreateProject(tenant)
canInviteUser(tenant)
canUseApi(tenant)
maxStorage(tenant)
hasFeature(tenant, "audit_log")

Теперь представим, что маркетинг завтра решает:

Давайте дадим API клиентам Start на 14 дней.

Если тарифы жёстко зашиты в десятки компонентов frontend и backend, даже такое изменение оказывается неприятным.

Гораздо устойчивее иметь централизованную entitlement-систему.

Условно:

Plan
    ↓
Entitlements
    ↓
Tenant Subscription
    ↓
Actual Permissions / Limits

Это дополнительная разработка.

Но она позволяет продукту нормально развиваться.

Feature flags и тарифы — не одно и то же

Эти понятия часто смешивают.

Entitlement отвечает:

Имеет ли этот клиент право использовать функцию?

Feature flag:

Включена ли эта реализация для данного сегмента пользователей?

Например, новый редактор доступен только 10% клиентов для тестирования.

Это feature flag.

А возможность экспортировать данные только на тарифе Business — entitlement.

Разделение этих механизмов делает развитие SaaS намного управляемее.

Шаг 6. Биллинг намного сложнее кнопки «Оплатить»

На макете:

Подписаться за 2990 ₽/месяц

После нажатия начинается настоящая логика.

Система должна понимать:

какая организация платит;

какой тариф выбран;

какой расчётный период;

успешен ли платёж;

когда наступает следующее списание;

что произошло после отказа банка;

сколько раз повторить попытку;

когда ограничить сервис;

можно ли восстановить подписку;

что делать при смене тарифа;

как рассчитывать частичную стоимость периода;

как обрабатывать webhook платёжного провайдера.

То есть появляется state machine подписки.

Например:

TRIAL
  ↓
ACTIVE
  ↓
PAST_DUE
  ↓
SUSPENDED
  ↓
CANCELED

Но возможны переходы назад:

PAST_DUE
   ↓ successful payment
ACTIVE

Состояния нужно синхронизировать с платёжным провайдером и при этом сохранять локальную консистентность.

Это уже не просто форма оплаты.

Webhook нельзя слепо считать новым уникальным событием

Платёжный провайдер может повторно отправить одно событие.

Если приложение каждый раз выполняет бизнес-операцию заново, появятся дубли.

Поэтому обработка событий должна быть идемпотентной.

Условно:

Webhook received
       ↓
Verify signature
       ↓
Check event_id
       ↓
Already processed?
   ↙             ↘
 yes              no
  ↓                ↓
return 200     process event
                    ↓
               save event_id

Для финансовых процессов такие детали нельзя оставлять «на потом».

А каждая из них увеличивает объём разработки и тестирования.

Шаг 7. Usage-based SaaS добавляет новый уровень сложности

Самый простой тариф:

2990 ₽ в месяц.

Гораздо сложнее:

2990 ₽ + 10 ₽ за каждую обработанную тысячу документов.

Теперь приложение должно измерять потребление.

Например:

Usage events
│
├── documents_processed
├── api_requests
├── storage_bytes
└── ai_tokens

Необходимо решить:

когда фиксировать usage;

можно ли отправить событие дважды;

как пересчитать показатели;

как хранить историю;

как формировать счёт;

как показывать расход пользователю.

Появляется отдельная metering-система.

Если экономика SaaS строится на usage-based pricing, это лучше учитывать ещё на архитектурном этапе.

Шаг 8. Административная панель SaaS — это отдельный продукт

Часто считают только клиентский интерфейс.

Но оператор платформы тоже должен чем-то пользоваться.

Например:

Администратор SaaS

├── Клиенты
├── Пользователи
├── Подписки
├── Платежи
├── Тарифы
├── Лимиты
├── Использование ресурсов
├── Ошибки интеграций
├── Состояние системы
└── Audit

Когда появляется проблема:

Клиент утверждает, что оплатил тариф, а доступ не открылся,

поддержке необходимо быстро понять, что произошло.

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

Хорошая SaaS-админка сокращает стоимость дальнейшего обслуживания продукта.

Но её разработка тоже входит в первоначальный бюджет.

Шаг 9. Onboarding напрямую влияет на объём разработки

Представим сложную B2B-платформу.

После регистрации пользователь видит пустой экран.

Технически продукт готов.

Практически клиент не понимает, что делать.

Появляется onboarding:

Создайте компанию
        ↓
Заполните профиль
        ↓
Пригласите сотрудников
        ↓
Создайте первый проект
        ↓
Подключите интеграцию
        ↓
Получите первый результат

Можно добавить:

progress indicator;

контекстные подсказки;

демонстрационные данные;

checklist;

email onboarding;

автоматические напоминания.

Каждый элемент увеличивает разработку.

Но для коммерческого SaaS путь от регистрации до первого полезного результата часто не менее важен, чем отдельные продвинутые функции.

Шаг 10. Интеграции необходимо считать отдельно

Формулировка:

Нужно интегрировать CRM.

для оценки практически бесполезна.

Нужно понимать:

какие данные отправляются;

какие приходят обратно;

кто является источником истины;

нужна ли двусторонняя синхронизация;

что происходит при конфликте;

есть ли rate limits;

как обрабатываются ошибки;

есть ли webhook;

как выполняется повторная синхронизация.

Простая интеграция:

SaaS → API → Service

может занять относительно немного времени.

Но двусторонний обмен:

SaaS
 ↑ ↓
Sync Engine
 ↑ ↓
External Service

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

Поэтому фраза «пять интеграций» ничего не говорит о трудоёмкости без анализа каждой из них.

Шаг 11. API для клиентов — это не просто открыть существующие endpoints

Допустим, SaaS должен предоставлять публичный API.

Теперь требуется решить:

как выдавать API-ключи;

как их отзывать;

можно ли иметь несколько ключей;

какие scopes существуют;

какие rate limits применяются;

как версионировать API;

как документировать методы;

как отслеживать usage;

что делать после изменения контракта.

Появляется отдельная поверхность продукта, которую необходимо поддерживать годами.

Внутренний endpoint:

/api/internal/projects

можно изменить одновременно с frontend.

Публичный:

/api/v1/projects

уже используется чужими системами.

Сломать его намного дороже.

Поэтому наличие публичного API необходимо учитывать в оценке как отдельное обязательство.

Шаг 12. Файловое хранилище — это не просто upload

Многие SaaS работают с пользовательскими файлами.

Тогда появляются:

лимиты;

типы файлов;

антивирусная проверка;

версии;

удаление;

временные ссылки;

разграничение доступа;

резервирование;

стоимость хранения;

очистка старых объектов.

Причём тариф может ограничивать объём:

Start: 5 GB
Business: 100 GB
Enterprise: custom

Следовательно, нужно считать использование ресурсов на tenant.

Иначе ограничение существует только на странице с тарифами.

Шаг 13. Email, push и мессенджеры формируют ещё одну подсистему

Простой продукт отправляет несколько писем.

Большой SaaS постепенно получает:

Notification Event
       ↓
Preference Engine
       ↓
 ┌─────┼─────┐
 ↓     ↓     ↓
Email  Web   Push
             ↓
          Telegram

Пользователь может захотеть:

получать критические уведомления по email;

обычные — только внутри приложения;

отключить маркетинговые письма;

получать еженедельный digest.

Если всё это смешать непосредственно с бизнес-кодом:

project.update()
sendEmail()
sendTelegram()
sendPush()

система быстро становится трудно изменяемой.

Поэтому зрелые SaaS обычно постепенно приходят к событийной модели уведомлений.

Она удобнее, но требует дополнительной разработки.

Шаг 14. Real-time увеличивает не только привлекательность интерфейса

Допустим, сервис должен мгновенно показывать:

новые сообщения;

изменение задачи;

статус обработки;

присутствие другого пользователя;

прогресс длительной операции.

Появляются WebSocket или другие real-time механизмы.

Но вместе с ними возникают вопросы:

что происходит после разрыва соединения;

как клиент восстанавливает пропущенные события;

как авторизовать подписку;

как изолировать события разных tenants;

как масштабировать соединения между несколькими экземплярами backend.

Поэтому слово «real-time» в требованиях необходимо воспринимать не как визуальную деталь, а как архитектурную характеристику.

Шаг 15. Аналитика бывает пользовательской и продуктовой

Пользователь хочет видеть:

Проекты: 138
Активные: 24
Выполненные: 114
Среднее время: 3,7 дня

Это продуктовая функция.

Команде самого SaaS нужны другие данные:

Signups
Activation
Trial → Paid
MRR
Churn
Feature usage
Retention
Errors
Performance

Это уже аналитика SaaS как бизнеса.

Плюс существуют технические метрики:

CPU
RAM
DB connections
Queue depth
Error rate
Latency
Disk
Storage

Все три уровня имеют разное назначение.

Если метрики нужны с первого релиза, их тоже необходимо включить в расчёт.

Шаг 16. Без observability стоимость поддержки становится непредсказуемой

Пока клиентов десять, разработчик может посмотреть логи вручную.

Когда клиентов тысяча, сообщение:

У нас иногда не сохраняется проект.

становится крайне неприятным.

Нужно знать:

какой пользователь;

какая организация;

какой запрос;

какая версия приложения;

сколько времени выполнялся запрос;

какая ошибка произошла;

были ли проблемы с базой или внешней системой.

Поэтому постепенно появляются:

structured logs;

metrics;

tracing;

error tracking;

health checks;

alerts.

Observability не создаёт видимой функции для клиента.

Но именно она позволяет обслуживать работающий SaaS без постоянного ручного расследования.

Шаг 17. Резервное копирование нужно проектировать до аварии

Фраза:

У нас база автоматически копируется,

ещё не означает надёжной стратегии.

Нужно понимать:

как часто создаются копии;

где они хранятся;

сколько времени сохраняются;

как восстанавливаются;

проверялось ли восстановление;

что происходит с файловым хранилищем;

какой объём данных допустимо потерять.

Полезные понятия:

RPO — сколько данных допустимо потерять.

RTO — сколько времени допустимо восстанавливать систему.

Одно дело — внутренний экспериментальный сервис.

Другое — SaaS, от которого зависит работа клиентов.

Требования будут разными, а вместе с ними различается инфраструктурная стоимость.

Шаг 18. Безопасность влияет на цену ещё до первой строки frontend

Чем больше данных хранит SaaS, тем серьёзнее требования.

В типичную область входят:

authentication;

authorization;

rate limiting;

CSRF/XSS-защита;

валидация данных;

secure cookies/tokens;

password reset;

session management;

audit log;

file validation;

secret management;

backup security;

tenant isolation.

При необходимости добавляются:

2FA;

SSO;

SAML/OIDC;

IP restrictions;

device sessions;

security events;

расширенный аудит.

Самый дешёвый момент подумать об этих механизмах — до того, как вокруг неправильной модели доступа построена вся система.

Шаг 19. Международный SaaS — ещё один уровень проекта

Фраза:

Потом выйдем на международный рынок.

может означать серьёзные изменения.

Появляются:

несколько языков;

разные валюты;

налоги;

форматы дат;

часовые пояса;

локализованные письма;

разные платёжные методы;

региональные требования;

возможная привязка хранения данных к региону.

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

Но реализовывать заранее десять языков для продукта без первых клиентов тоже нет необходимости.

Как перевести всё это в часы

После определения архитектуры проект можно декомпозировать.

Рассмотрим условный пример, а не рыночный прайс-лист.

Допустим, создаётся B2B SaaS средней сложности.

Получаем около:

3010 часов.

Добавим, например, 15% резерва на изменения требований и технические неизвестные:

≈ 3460 часов.

Теперь бюджет можно рассчитывать через стоимость команды.

Если эффективная ставка составляет условные 3000 ₽/час:

≈ 10,4 млн ₽.

При 2000 ₽/час:

≈ 6,9 млн ₽.

При 5000 ₽/час:

≈ 17,3 млн ₽.

Это не означает, что SaaS обязательно стоит столько.

Смысл примера другой:

одна и та же формула бюджета становится понятной только после декомпозиции системы.

Почему оценка «по количеству страниц» почти бесполезна

Представим два интерфейса.

В обоих десять страниц.

Первый:

Главная
Проекты
Задачи
Профиль
...

Второй выглядит почти так же.

Но в нём:

multi-tenancy;

custom roles;

billing;

usage limits;

real-time collaboration;

audit log;

API;

SSO;

несколько интеграций.

Количество страниц одинаковое.

Объём backend-логики отличается в несколько раз.

Именно поэтому цена за экран подходит разве что для очень приблизительных дизайнерских работ, но плохо подходит для оценки сложного SaaS.

Что сильнее всего раздувает бюджет

Обычно не кнопки и не формы.

Сильнее влияют правила и связи.

Например:

Пользователь может редактировать документ.

Просто.

Теперь:

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

Это уже значительно более сложное правило.

Добавим:

Enterprise-клиенты могут создавать собственный workflow согласования.

Система становится ещё сложнее.

Количество интерфейсных элементов почти не изменилось.

Изменилась сложность состояний.

Полезно считать количество переменных бизнес-правил

Перед оценкой можно выписать:

• роли;
• статусы;
• тарифы;
• лимиты;
• типы пользователей;
• типы организаций;
• workflows;
• способы оплаты;
• интеграции;
• типы документов.

Чем больше эти сущности влияют друг на друга, тем выше сложность.

Особенно опасны требования вида:

Если компания находится на Business, пользователь является руководителем отдела и документ относится к проекту типа X, разрешить действие только после согласования сотрудником с ролью Y.

Каждое такое правило нужно разработать, протестировать и поддерживать.

MVP SaaS тоже должен быть SaaS

Можно сократить количество функций.

Например, первая версия может не иметь:

конструктора отчётов;

публичного API;

десяти интеграций;

кастомных ролей;

расширенной аналитики;

white label.

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

Хороший SaaS MVP может быть функционально небольшим, но его фундамент должен соответствовать модели продукта.

Пример разумного MVP

Допустим, конечная платформа должна содержать:

CRM
Документы
Задачи
AI-модуль
Конструктор автоматизаций
API
Интеграции
Отчёты
Мобильное приложение
White label

Для первого релиза можно оставить:

Регистрация
    ↓
Организация
    ↓
Приглашение команды
    ↓
Основная бизнес-функция
    ↓
Тариф
    ↓
Подписка
    ↓
Базовая админ-панель

Но сделать нормально:

tenant isolation;

роли;

миграции базы;

резервирование;

логирование;

проверку платежей;

безопасность.

Так первая версия остаётся развиваемой.

Когда SaaS не стоит сразу строить как огромную платформу

Есть и противоположная ошибка.

Планируя будущий рост, команда начинает с:

Kubernetes;

20 микросервисов;

нескольких брокеров;

отдельной аналитической платформы;

сложной event-driven архитектуры;

нескольких баз данных.

При этом продукт ещё не имеет платящих клиентов.

Получается технически впечатляющая инфраструктура, которую маленькой команде дорого обслуживать.

Для многих новых SaaS хорошей стартовой точкой оказывается:

Frontend
    ↓
Modular Backend
    ↓
PostgreSQL

+ Object Storage
+ Queue при необходимости
+ Redis при необходимости
+ Monitoring

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

Если нагрузка действительно вырастет, узкие места можно выделять уже на основании реальных данных.

Микросервисы сами по себе не делают SaaS масштабируемым

Можно создать 30 сервисов и получить медленную, хрупкую систему.

Можно иметь хорошо спроектированный монолит и обслуживать большой объём трафика.

Масштабируемость зависит от:

характера нагрузки;

индексов базы;

кэширования;

фоновых задач;

архитектуры данных;

горизонтального масштабирования;

объёмов I/O;

узких мест.

Поэтому выбор микросервисов должен решать конкретную проблему.

Использовать их только потому, что продукт называется SaaS, необязательно.

Инфраструктурный бюджет — это отдельная статья расходов

Стоимость разработки и стоимость эксплуатации — разные показатели.

После запуска появляются регулярные затраты:

серверы;

managed database или собственная БД;

объектное хранилище;

CDN;

email;

SMS;

мониторинг;

backup;

внешние API;

платёжная инфраструктура;

AI API, если используется;

техническая поддержка.

Причём часть затрат зависит от количества пользователей.

Поэтому ещё до запуска полезно построить приблизительную unit economics инфраструктуры.

Например:

Стоимость инфраструктуры
────────────────────────
фиксированная часть
+
стоимость на tenant
+
стоимость на пользователя
+
usage-зависимые внешние API

Иначе может оказаться, что тариф приносит 500 ₽, а обслуживание активного клиента обходится почти столько же.

Цена разработки и цена владения — не одно и то же

Предположим, вариант A дешевле разработать на 500 тысяч рублей.

Но он требует постоянной ручной обработки:

ошибок подписок;

сбоев интеграций;

лимитов;

обращений клиентов;

миграций.

Вариант B дороже на старте, но имеет нормальную admin tooling и автоматизацию.

Через два года второй вариант вполне может оказаться дешевле.

Поэтому SaaS разумно оценивать хотя бы в двух измерениях:

Cost to Build

и

Cost to Operate.

Иногда третьим показателем становится Cost to Change

Для SaaS особенно важна способность продукта меняться.

Тарифы будут меняться.

Функции будут меняться.

Появятся новые типы клиентов.

Маркетинг захочет эксперименты.

Продуктовая команда изменит onboarding.

Появятся новые интеграции.

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

Поэтому полезно рассматривать:

Cost to Build — сколько стоит создать.

Cost to Operate — сколько стоит обслуживать.

Cost to Change — насколько дорого развивать.

Хорошая архитектура старается удерживать все три показателя в разумных пределах.

Как получить предварительную оценку без огромного ТЗ

Для первого расчёта необязательно писать документ на 300 страниц.

Можно начать с нескольких блоков.

1. Описать клиентов

Например:

Клиенты:
малый и средний бизнес

В организации:
1–50 пользователей

Один пользователь:
может состоять в нескольких организациях

2. Описать основную ценность

Что пользователь получает такого, ради чего готов платить?

3. Нарисовать основной сценарий

Регистрация
    ↓
Создание workspace
    ↓
Настройка
    ↓
Основная операция
    ↓
Получение результата

4. Описать монетизацию

Подписка?

Оплата за пользователя?

Usage-based?

Бесплатный тариф?

Trial?

5. Определить интеграции

Каждую отдельно.

6. Определить требования к безопасности

Какие данные хранятся?

Насколько критична их утечка?

7. Определить ожидаемую нагрузку

Не «сервис должен выдерживать много пользователей», а хотя бы порядок величин.

После этого уже можно выполнить декомпозицию.

Как должна выглядеть нормальная предварительная оценка

Не так:

SaaS будет стоить 4 миллиона.

А примерно так:

Discovery              100–140 ч
UX/UI                  140–200 ч
Core                   450–600 ч
Tenant platform        180–260 ч
Roles                  80–120 ч
Billing                120–180 ч
Integrations           100–220 ч
Admin                  100–160 ч
QA                     220–320 ч
DevOps                  80–130 ч
...

Рядом перечисляются предположения.

Например:

• три фиксированные роли;
• один платёжный провайдер;
• одна валюта;
• без SSO;
• без мобильного приложения;
• две интеграции;
• одна основная tenant-модель.

Теперь заказчик видит, из чего состоит стоимость.

Если появляется новое требование:

Нужен Enterprise SSO,

можно показать, какой блок изменился и почему.

Это намного прозрачнее одной итоговой цифры.

Почему диапазон честнее точной цены на раннем этапе

До discovery невозможно знать все детали.

Поэтому:

1800–2300 часов

на ранней стадии часто является более профессиональной оценкой, чем:

2047 часов.

Вторая цифра выглядит точнее.

Но эта точность искусственная.

По мере анализа диапазон можно уменьшать.

Например:

Идея:
1800–3000 ч

После discovery:
2100–2500 ч

После технического проектирования:
2250–2420 ч

Чем больше неизвестных снято, тем выше точность.

Какие вопросы обязательно задать исполнителю

Перед началом SaaS-разработки полезно понять не только итоговую цену.

Стоит спросить:

Как реализуется изоляция данных разных клиентов?

Как устроена модель ролей и разрешений?

Как будут работать тарифы и ограничения?

Как обрабатываются повторные webhook платежей?

Что произойдёт при недоступности внешней интеграции?

Как выполняются миграции базы?

Как восстанавливаются резервные копии?

Как диагностируется ошибка конкретного клиента?

Как система будет масштабироваться при росте?

Какие элементы первой версии считаются временными?

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

Красные флаги в оценке SaaS

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

Другой сигнал:

Авторизацию, оплату и админку добавим потом — там ничего сложного.

Ещё один:

Сначала запустим, безопасность сделаем после появления пользователей.

Или:

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

Каждая из этих фраз может скрывать отсутствие анализа.

Сильная оценка обычно содержит не только цифру, но и список предположений, рисков и границ проекта.

Можно ли заметно уменьшить стоимость SaaS?

Да.

Но лучше сокращать объём, а не качество фундамента.

Например, можно отложить:

• mobile app;
• advanced analytics;
• custom roles;
• white label;
• публичный API;
• десять вторичных интеграций;
• сложные автоматизации;
• конструкторы отчётов.

При этом сохранить:

• корректную tenant-модель;
• миграции;
• базовую безопасность;
• резервирование;
• нормальные права;
• логирование;
• устойчивый billing.

Так первая версия становится дешевле без превращения в технический тупик.

Практический пример сокращения проекта

Изначально:

Собственный SaaS
├── Web
├── iOS
├── Android
├── 4 тарифа
├── Custom roles
├── Public API
├── 12 интеграций
├── Advanced analytics
├── White label
└── Automation builder

После анализа первого релиза:

Web
├── 2 тарифа
├── 3 фиксированные роли
├── Основной workflow
├── Billing
├── 2 критические интеграции
├── Базовая аналитика
└── Admin panel

При этом архитектура допускает дальнейшее расширение.

Такой подход способен сократить первый этап в разы, не отказываясь от будущей продуктовой стратегии.

Когда полноценный SaaS действительно стоит дорого

Высокая стоимость становится логичной, если системе одновременно нужны:

сложная multi-tenant модель;

множество ролей;

финансовые операции;

кастомные workflows;

большое количество интеграций;

real-time;

публичный API;

сложная аналитика;

большие объёмы данных;

высокие требования к отказоустойчивости;

международная локализация;

Enterprise-функции.

Тогда речь уже идёт не о сайте и не о наборе форм.

Фактически создаётся самостоятельная программная платформа.

Поэтому сколько стоит SaaS?

Правильный ответ обычно выглядит не как одна цифра.

Можно использовать ориентиры по трудоёмкости.

Например:

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

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

После этого часы переводятся в бюджет команды.

Но намного важнее сначала понять, почему получилось именно такое количество часов.

Вместо вывода

Стоимость SaaS определяется не количеством страниц.

И даже не количеством функций в привычном понимании.

На бюджет особенно сильно влияют вещи, которые пользователь часто вообще не видит:

изоляция tenants;

права доступа;

подписки;

тарифные ограничения;

обработка платежей;

идемпотентность;

интеграции;

фоновые процессы;

аудит;

резервное копирование;

мониторинг;

административные инструменты.

Именно поэтому два визуально похожих SaaS могут отличаться по стоимости разработки в несколько раз.

Хорошая оценка начинается с пяти вопросов:

Кто является клиентом системы?

За какую ценность он платит?

Как изолируются его данные?

По каким правилам работают тарифы и доступ?

Какие процессы должны оставаться надёжными даже при сбоях внешних систем?

После этого SaaS декомпозируется на модули.

Модули — на сценарии.

Сценарии — на задачи.

И только затем появляется стоимость.

Так бюджет перестаёт быть случайной цифрой из коммерческого предложения.

Он становится следствием конкретной архитектуры, бизнес-модели и набора требований — а значит, его можно обсуждать, оптимизировать и контролировать.