SaaS-платформа — облачный продукт по подписке, где пользователь постоянно работает внутри сервиса, а не изучает информацию. MVP делается за 2–3 месяца и стоит от 2 миллионов рублей, полноценная платформа с биллингом — от 4,5 миллиона.
Но не спешите проектировать мультитенантность и сложный биллинг сразу. Не каждому SaaS они нужны с первого релиза, и это решение экономит половину бюджета MVP.
SaaS или коробочное решение
Разница не в том, что одно живёт в облаке, а другое ставится на сервер. Разница в том, как им пользуются.
Посетитель сайта изучает информацию и уходит. Пользователь SaaS постоянно работает внутри продукта: вводит и получает данные, выполняет операции, взаимодействует с другими участниками процесса. Это меняет всё — от структуры аккаунтов до того, как система будет развиваться после запуска.
Коробочное ПО устанавливается у каждого клиента отдельно. SaaS — одна платформа, одна кодовая база, все клиенты обслуживаются централизованно. Владелец продукта выпускает обновление один раз, и оно доходит до всех сразу — не нужно повторять миграцию версия за версией у каждого клиента.
Практическое следствие: коробочное ПО обычно дороже в поддержке и медленнее развивается. Каждое исправление ошибки в SaaS — это одно изменение для всех, а не пятьдесят повторяемых развёртываний.
Пример: «Портал» — собственный продукт в двух форматах
«Портал» мы развиваем сами: корпоративное рабочее пространство с базой знаний, процессами и кадровым контуром. Он существует в двух форматах — установка на серверы заказчика и отдельный SaaS-сервис. Для одних компаний важна подписка и быстрый старт, для других — закрытый контур. Одна кодовая база обслуживает оба случая, поэтому исправления и новые модули доходят до всех клиентов одновременно.
Модули «Портала» выросли из проектов, которые мы делали на заказ: корпоративные порталы и HRM-системы для крупных компаний.
Мультитенантность: когда нужна и когда нет
Расхожее заблуждение: раз это SaaS, значит нужна мультитенантная архитектура. Нет.
Мультитенантность — это когда одна платформа обслуживает сотни и тысячи разных клиентов, а данные каждого логически изолированы. Технически — горизонтальное масштабирование, кластер, распределение нагрузки.
Она нужна, если платформой пользуются разные компании с разделением данных. Если сервис изначально рассчитан на одну организацию или на группу пользователей без чужих данных рядом — подходит архитектура попроще, и она дешевле.
Это разворот, который стоит проговорить прямо: не проектируйте мультитенантность просто потому что «у больших так принято». Она добавляет сложность и стоимость, а окупается только если у вас действительно много независимых клиентов на одной платформе.
Что входит в MVP, а что можно отложить
Самый практичный совет во всей статье: не каждый SaaS нуждается в мультитенантности или сложном биллинге с первого релиза.
Что реально нужно в первой версии:
- основной пользовательский сценарий;
- авторизация;
- необходимые роли — ровно те, что нужны для сценария, не больше;
- ключевой модуль, ради которого всё затевается;
- базовая административная панель.
Отдельно про white-label: если продукт задуман как решение, которое партнёры будут предоставлять под своим брендом и доменом, это тоже решается на этапе архитектуры, а не пристраивается потом.
Подписка и оплата включаются в MVP, только если они нужны для проверки самой гипотезы монетизации. Если гипотеза не про деньги, а про спрос — можно выставлять счета вручную первые месяцы.
Отдельно про роли. Их стоит продумывать вместе со структурой продукта с самого начала, а не добавлять после того как модули уже написаны. В сложном B2B-продукте права могут зависеть от подразделения, проекта, тарифа или типа операции — переделывать эту логику задним числом дорого.
Что входит в первую версию, а что откладываем
| Входит в MVP | Откладываем |
|---|---|
| Основной пользовательский сценарий | Мультитенантность, если клиентов пока единицы |
| Авторизация | Сложный биллинг: счета можно выставлять вручную |
| Роли, ровно те, что нужны для сценария | Расширенная аналитика |
| Ключевой модуль, ради которого всё затевается | White-label для партнёров |
| Базовая административная панель | Публичный API |
Тарифы и биллинг
В биллинг обычно входит: тарифы с лимитами, пробный период, автоматическое продление, счета и закрывающие документы, апгрейд и даунгрейд тарифа, приостановка доступа при неоплате.
Из платёжных систем для российского рынка чаще всего берут Stripe (если есть иностранные клиенты), ЮKassa, ЮMoney и эквайринг напрямую от банков.
Но здесь тот же принцип, что и с мультитенантностью: не каждый SaaS нуждается в сложном биллинге сразу. Правила биллинга проектируются вместе с бизнес-моделью — это помогает избежать ситуации, когда готовую архитектуру приходится ломать из-за нового способа оплаты, придуманного через полгода.
| Уровень | Что входит в биллинг |
|---|---|
| Минимальный | Ручные счета, оплата по реквизитам, ручное включение и отключение доступа |
| Стандартный | Тарифы с лимитами, пробный период, автопродление, счета и закрывающие документы, приостановка доступа при неоплате |
| Полный | Всё из стандартного, плюс апгрейд и даунгрейд тарифа, пропорциональный пересчёт, несколько валют и юрлиц |
Сроки и бюджет SaaS-платформы
| Уровень | Что входит | Срок | Бюджет |
|---|---|---|---|
| MVP | Основной сценарий, авторизация, роли, ключевой модуль, базовая админка | 2–3 месяца | 2,1–3,2 млн ₽ |
| Стандартная платформа | Тарифы и автопродление, интеграции, продуктовая аналитика | 4–6 месяцев | 4,5–6,7 млн ₽ |
| Enterprise | Мультитенантность, полный биллинг, высокая нагрузка, требования по безопасности | От 6 месяцев | 10,6–16 млн ₽ |
Цена зависит от объёма работ, а не от размера компании-подрядчика: две платформы с одинаковым списком функций могут отличаться в смете из-за мультитенантности, сложности биллинга и числа интеграций.
Точную смету готовим после брифинга и составления ТЗ. Это порядок цифр, а не предложение: Получить расчёт под вашу задачу
1С, CRM, банк, ЭДО, телефония, маркетплейсы — каждая +40 часов
Ориентир бюджета
4,7–7,1 млн ₽
Фактическая стоимость, сроки и состав команды утверждаются с заказчиком индивидуально.
Fix Price или Time & Material
Fix Price — фиксированная смета под утверждённое ТЗ. Работает, когда требования устаканились и меняться не будут.
Time & Material — оплата по факту, если объём заранее не зафиксирован. Гибкое управление приоритетами, можно ускорять или замораживать задачи без штрафов.
Отдельно стоит сказать про оплату: постоплата по этапам — норма рынка, не уступка со стороны подрядчика. Схема обычно такая — фиксируем этап, сдаём результат, проводите приёмку, только потом оплата. Предоплата 0% у части подрядчиков — не редкость.
| Критерий | Fix Price | Time & Material |
|---|---|---|
| Когда подходит | ТЗ устаканилось | Требования уточняются по ходу |
| Гибкость | Низкая, доплаты через допсоглашение | Высокая |
| Предсказуемость бюджета | Высокая | Средняя |
| Оплата | По этапам после приёмки | По факту часов |
Интеграции и публичный API
Здесь SaaS отличается от корпоративной системы принципиально. В корпоративной разработке API нужен вам самим, чтобы связать системы внутри своего контура. В SaaS публичный API нужен вашим клиентам — чтобы встраивать ваш продукт в свою инфраструктуру.
Это другой уровень требований: документация, версионирование, обратная совместимость, лимиты на запросы, webhook для уведомлений.
Типовые точки интеграции: CRM, 1С и ERP, платёжные сервисы, телефония и мессенджеры, карты и доставка, электронная подпись. Протоколы — REST, иногда SOAP для старых корпоративных систем, GraphQL для гибкой выборки данных.
На чём строят SaaS-платформу
Типовой набор технологий на рынке, исходя из нашей практики, по слоям:
- Backend: Go и Rust для высоконагруженных API и сервисов, где важны производительность и простая эксплуатация; Python и Node.js — для вспомогательных задач.
- Frontend: Svelte 5 / SvelteKit и HTMX, TypeScript для типизации — быстрее, надёжнее и легче. По желанию заказчика — React или Vue.
- База данных: PostgreSQL по умолчанию для данных с транзакциями, ClickHouse для аналитики, MongoDB для гибких схем, а в решениях с локальной LLM и RAG — векторная база данных.
- Инфраструктура: российские облака — Selectel, Yandex Cloud, VK Cloud и другие; Docker, Kubernetes для оркестрации; CI/CD через GitLab или GitHub, при необходимости — на собственном Git-сервере заказчика, например GitLab Self-Managed.
- Мониторинг: Grafana и смежные инструменты для метрик, логов и ошибок.
Нагрузочное тестирование перед запуском — стандартная практика, ориентир 500–5000 запросов в секунду для обычного пакета, до 10 000+ RPS в Enterprise-конфигурации.
На чём строим мы:
| Слой | Что берём | Зачем |
|---|---|---|
| Серверная часть | Go | Устойчивость под нагрузкой и простая эксплуатация: один сервис — один исполняемый файл |
| Данные | PostgreSQL | Транзакции для платежей и подписок, изоляция данных клиентов |
| Долгие процессы | Temporal | Биллинг, онбординг и продление — многошаговые процессы, которые не теряются при сбоях и повторяются безопасно |
| Интерфейс | Svelte 5, SvelteKit | Лёгкий клиентский код, быстрая загрузка кабинета |
| Развёртывание | Docker, Ansible | Одинаковое окружение на тесте и проде |
AI внутри платформы и требования 152-ФЗ
AI в SaaS — не отдельный чат с нейросетью сбоку, а встроенный AI-ассистент с доступом к данным платформы и ограничениями по ролям.
Конкретные функции, которые реально встраивают:
- ответы по базе знаний и документам через RAG;
- поиск по платформе обычными фразами, без сложных фильтров;
- анализ документов, заявок и переписки;
- автоматическое заполнение карточек и полей;
- классификация и распределение обращений;
- выполнение действий в сервисе: создать задачу, сформировать отчёт, изменить статус.
Разница с обычным чат-ботом в том, что у ассистента есть доступ именно к данным вашего продукта — его ролям, его записям, его процессам — а не только к общим знаниям модели.
Отдельно — требования для российского рынка. 152-ФЗ требует хранения персональных данных на серверах в РФ (Yandex Cloud, VK Cloud, Selectel — типовой выбор), шифрования на уровне транспорта и хранилища, ролевой модели доступа и журналирования действий. Это закладывается в архитектуру с самого начала, а не добавляется перед проверкой.
После запуска: аналитика и доработка
После релиза важно понимать не просто «сколько людей зарегистрировалось», а кто дошёл до платного тарифа и остался.
Что стоит отслеживать: регистрации и активацию аккаунтов, переход на платный тариф, возврат пользователей (retention), отток (churn), ARR и MRR. Аналитика помогает отличить востребованные функции от тех, которыми почти не пользуются — план следующих версий строится на этом, а не на интуиции.
Отдельный сценарий — доработка уже существующего SaaS чужой командой. Здесь работа всегда начинается с аудита: код, архитектура, база данных, инфраструктура, интеграции. И честное предупреждение: не обещайте полный рефакторинг до аудита. Состояние унаследованного проекта может сильно повлиять на реальные сроки и стоимость — иногда переписать оказывается дешевле, чем чинить, а иногда наоборот.
Начните с одного вопроса: нужна ли вам мультитенантность прямо сейчас, или можно обойтись без неё в первой версии. Ответ на него сдвигает бюджет MVP сильнее, чем выбор подрядчика.
Не продаём коробку. Разрабатываем то, что действительно нужно бизнесу.
Опишите продукт и клиентов, которым вы его хотите дать: кто платит, за что и как часто. Подскажем, что нужно в первой версии, а что можно отложить, и назовём предварительные сроки.
Первый разговор ни к чему не обязывает: после него будет понятно, нужна ли вам мультитенантность сейчас и сколько стоит первая версия.
Если гипотеза ещё не проверена — разработка MVP. Если клиенты — юрлица с договорными ценами — B2B-платформа. Если задача во внутреннем контуре без подписки — корпоративный портал.