Scenario · 01
“Идея и первые пользователи”
У вас есть продуктовая идея, первые интервью или ранние пользователи. Нужна первая рабочая версия SaaS с организациями, ролями, тарифной логикой и понятным планом развития после запуска.
Направление · SaaS
B2B SaaS V1 за 6–12 недель.
Первая рабочая версия подписочного продукта для основателей и растущих команд: организации, роли, тарифная логика, платёжный контур, админ-панель и продакшен-запуск — с архитектурой, которую можно развивать после первых клиентов.
01 · Для кого мы строим
К нам приходят основатели на четырёх стадиях.
У каждой стадии — свои риски и свой объём работ. Мы фиксируем стадию на первой встрече и предлагаем формат, который реально соответствует ситуации.
Scenario · 02
“Готовимся к запуску или технической проверке”
У вас уже есть финансирование, партнёр или подтверждённый спрос. Нужна первая версия SaaS с понятной архитектурой, журналированием, мониторингом и документацией — чтобы продукт было проще запускать, проверять и развивать.
Scenario · 03
“Внутренний инструмент — превращаем в SaaS”
У вас есть работающий внутренний инструмент. Хотите вынести его как SaaS для внешнего рынка — с мульти-арендностью, подписками, ролевой моделью и изоляцией данных клиентов.
Scenario · 04
“Проект сломан — подрядчик ушёл или продукт не работает”
У вас уже есть SaaS, но новые функции добавлять рискованно: роли запутаны, биллинг нестабилен, данные клиентов изолированы неправильно или продукт не удалось нормально запустить. Подключаемся через диагностику — без обвинений, с планом стабилизации.
02 · Что входит в первую версию
Не кликабельный прототип, а первая рабочая версия продукта.
Первая версия работает в продакшене: пользователи входят в свои организации, используют основной сценарий продукта, а команда управляет пользователями, тарифами и операциями через админ-панель. Платёжный контур подключается, если он нужен для первого запуска.
Мульти-арендность
Если продукт рассчитан на несколько клиентских организаций, модель изоляции данных проектируем на старте: общая схема с tenant_id, отдельные схемы или отдельные базы — в зависимости от требований к изоляции, стоимости эксплуатации, восстановлению данных и договорным обязательствам перед клиентами.
Бэкенд и данные
Java / Spring Boot или TypeScript backend — выбираем по доменной сложности, интеграциям и требованиям к эксплуатации. PostgreSQL — основная база. Redis, очереди и отдельное аналитическое хранилище добавляем только там, где этого требует нагрузка или продуктовый сценарий.
Подписки и биллинг
Для российского платёжного контура рассматриваем ЮKassa, интернет-эквайринг Т-Бизнеса и поддерживаемые сценарии оплаты через СБП. Реализуем тарифную модель, статусы подписки, ограничения функций, возвраты и webhook-обработку платёжных событий. Передачу данных для чеков и требования к фискализации клиент подтверждает со своим бухгалтером или профильным консультантом. Международный платёжный контур оценивается отдельно под юридическую структуру продукта и доступность провайдера.
Авторизация, роли и доступы
Авторизация, роли и права доступа проектируются вокруг организаций и действий внутри продукта. Для B2B-сценариев могут потребоваться корпоративный SSO, двухфакторная аутентификация для команды, журнал чувствительных действий и усиленная модель доступа — если это нужно первой продаже или требованиям клиента.
Фронтенд и кабинеты
Кабинет клиента с правильной информационной архитектурой, админ-панель оператора и публичные продуктовые страницы там, где они нужны. Next.js App Router, React, TypeScript strict, адаптивность от 320 px до 4K. Публичный SEO-слой подключается только продуктам, которым нужен внешний каталог или лидогенерация.
Аналитика и метрики продукта
Базовые события продукта закладываем в первую версию: регистрация, активация, ключевое действие, переход на оплату и удержание — если это применимо к модели продукта. Инструмент аналитики и глубина отчётности определяются под scope; отдельное хранилище аналитики добавляется только при необходимости.
Деплой, инфраструктура и передача
Docker, CI/CD через GitHub Actions, тестовое и продакшен-окружения, мониторинг ошибок и резервные копии. Для продуктов, которые собирают персональные данные граждан РФ, инфраструктурную схему проектируем с российским контуром хранения данных. Международная инфраструктура рассматривается отдельно для допустимых сценариев и зарубежных рынков. GitHub-репозиторий, документация и доступы остаются у вас.
Опциональный модуль · AI
AI-функции — только отдельным scope.
AI-функции добавляем только отдельным scope, если они усиливают основной сценарий продукта: поиск по документам, классификация обращений, черновики или помощь оператору. Требования к данным, модели, human review и журналированию определяются отдельно. Подробнее — в направлении AI и автоматизация (/ru/ai).
- ×Поиск по корпоративным документам и базе знаний — когда у пользователей много неструктурированного контента.
- ×Классификация входящих обращений и черновики ответов — когда правильная маршрутизация ощутимо снижает нагрузку на операторов.
- ×Архитектура с человеком в процессе: AI готовит, оператор подтверждает; ключевые решения остаются в детерминированной бизнес-логике.
- ×Модель (внешняя или локальная), маршрутизация данных, журнал AI-операций и допустимость внешнего AI-контура определяются под проект.
- ×Юридическую оценку применимости 152-ФЗ при передаче данных в AI-контур подтверждает профильный юрист клиента.
03 · Три ключевых архитектурных решения
Самые дорогие решения принимаются до старта.
- 01
Как изолировать данные клиентских организаций?
Для SaaS с несколькими организациями модель изоляции выбирается на старте. Общая схема с tenant_id обычно проще в эксплуатации и обновлениях. Отдельные схемы или отдельные базы рассматриваем, когда нужны усиленная изоляция, восстановление данных на уровне клиента или договорные требования заказчиков. Выбор зависит не от ярлыка SMB / enterprise, а от риска, стоимости эксплуатации и модели продаж.
- 02
Как устроить тарифы и платёжный контур?
Для российского продукта рассматриваем доступные платёжные решения, включая ЮKassa и интернет-эквайринг Т-Бизнеса. Реализуем тарифы, доступность функций, статусы оплаты, возвраты и обработку событий провайдера. Фискальную и налоговую модель подтверждает клиент со своим бухгалтером или консультантом. Международный платёжный контур оценивается отдельно под юридическое лицо и поддерживаемую провайдером юрисдикцию.
- 03
Стек: модульный монолит или отдельные сервисы?
Модульный монолит — вариант по умолчанию для первой версии: понятные доменные границы и простой деплой. Отдельные сервисы добавляем только там, где это оправдано независимым масштабированием, изоляцией данных, интеграционной нагрузкой или требованиями эксплуатации.
04 · Технический стек
Стек, проверенный в продакшене.
Не подбираем по моде. Каждая технология здесь — на проектах, которые мы поставили в продакшен и поддерживаем дальше. Конкретный выбор фиксируется на архитектурном спринте под ваш контекст.
Бэкенд
- Java · Spring Boot
- Spring Security · Hibernate
- Node.js · TypeScript
Java и Spring Boot — когда нужна предсказуемость и зрелые библиотеки. Node.js — когда быстрый итеративный цикл важнее.
Фронтенд
- Next.js App Router
- React · TypeScript strict
- SCSS Modules · Tailwind CSS
- React Query · Zod
Один визуальный язык в кабинете клиента, админ-панели оператора и публичных страницах. Серверный рендеринг для маркетинга, авторизованные сценарии для продукта.
Базы данных и кэш
- PostgreSQL
- Redis
- ClickHouse
- S3-совместимое хранилище
PostgreSQL — основная база со схемой под выбранную модель изоляции. Redis — кэш и сессии. ClickHouse — когда нужна аналитика на больших объёмах.
Платежи
- ЮKassa · Т-Бизнес
- СБП — где поддерживается выбранным сценарием
- Международный контур — отдельно по структуре продукта
Для российского продукта подключаем согласованный платёжный контур и серверную логику тарифов, оплат, возвратов и webhook-событий. Требования к чекам и фискализации подтверждает клиент. Международные провайдеры рассматриваются только при подходящей юридической и платёжной структуре.
Инфраструктура и наблюдаемость
- Российский контур · ПД граждан РФ
- Международный — допустимые сценарии
- Docker · GitHub Actions
- Nginx · Sentry · бэкапы
Инфраструктура выбирается под состав данных, рынок продукта и требования клиента. Юридическую оценку обработки персональных данных и трансграничной передачи подтверждает профильный специалист клиента.
AI и автоматизация
- Отдельный scope · направление /ru/ai
AI-функции не входят в базовый SaaS-scope и оцениваются отдельно в направлении «AI и автоматизация».
05 · Открытые цены · Без скрытых пунктов
От архитектурного спринта до запуска.
Пять форматов с гибкой комбинацией: можно начать с любого и остановиться после него. План работ и точная смета на следующий этап остаются у вас. Сфокусированная SaaS V1 обычно укладывается в 8–12 недель после утверждения scope; более сложные продукты оцениваются отдельно.
Архитектура
Архитектурный спринт
Карта продукта, решение по модели изоляции данных, выбор платёжного контура, стек с обоснованием, точная смета на дальнейшие этапы. Документ остаётся у вас и работает с любой командой.
├5 дней┤
- Карта продукта и сценариев
- Модель организаций и изоляции данных
- Выбор платёжного контура и стека
- Список рисков с приоритетом
- Roadmap до запуска по неделям
- Точная смета на следующий этап
SaaS V1
SaaS V1
Первая рабочая версия подписочного продукта для первых пользователей и клиентов: организации, роли, тарифная логика, основной пользовательский сценарий, админ-панель, платёжный контур при необходимости, аналитика, мониторинг и передача.
├8–12 недель┤
- Организации и роли
- Основной пользовательский сценарий
- Тарифная логика и ограничения функций
- Платёжный контур — если нужен запуску
- Админ-панель оператора
- Базовая аналитика и мониторинг
- Документация и передача
Расширенный B2B SaaS
Расширенный B2B SaaS
Для продуктов, где уже в первой версии нужны несколько типов клиентов, корпоративный доступ, интеграции, расширенное журналирование, более глубокая админ-панель и документация для технической проверки.
├12–20 недель┤
- Всё из SaaS V1
- Расширенная ролевая модель
- SSO — если нужен корпоративным клиентам
- Интеграции с внешними системами
- Журнал чувствительных действий
- Расширенная админ-панель
- Документация для технической проверки
Стабилизация
Стабилизация существующего SaaS
Когда первая версия стала хрупкой и новые функции добавлять всё сложнее. Архитектурное ревью, рефакторинг проблемных мест, оценка модели организаций и изоляции данных, исправление тарифной и платёжной логики, если она входит в проблему. Без полного переписывания, где это возможно.
├4–12 недель┤
- Архитектурное ревью существующего кода
- План стабилизации с приоритетами
- Рефакторинг проблемных мест
- Оценка модели организаций и изоляции данных
- Исправление тарифной и платёжной логики, если она входит в проблему
- Документация для дальнейшей разработки
Партнёрство
Развитие и поддержка
Та же команда после запуска: новые функции, мониторинг, архитектурные ревью, интеграции и развитие продукта.
├помесячно┤
- Новые функции по приоритетам
- Архитектурные ревью каждый спринт
- План работ на месяц и отчёты
- Поддержка деплоя и инфраструктуры
- Документация обновляется вместе с кодом
06 · Почему H-Studio для SaaS
Первая версия, которую можно развивать дальше.
- 01
Первая версия без технического тупика
SaaS может меняться после первых клиентов — это нормально. Мы проектируем первую версию так, чтобы продукт не пришлось срочно перестраивать только потому, что на старте не были продуманы организации, роли, тарифная логика, данные, админ-панель или критичные интеграции.
- 02
Организации, роли и тарифная модель — на старте
Если продукт рассчитан на несколько клиентских организаций и подписочную модель, решения по изоляции данных, правам доступа, тарифам и платёжному контуру принимаются до разработки ключевых сценариев. Не добавляем их как запоздалую надстройку после запуска.
- 03
Senior-команда от спринта до запуска
Та же senior-команда ведёт проект от архитектурного спринта до запуска. Ключевые решения по данным, ролям, тарифам, интеграциям и эксплуатации остаются у инженерного лида.
- 04
Код, доступы и документация — у вас
Код в вашем GitHub. Архитектурная документация. Доступы ко всем сервисам. Схема деплоя. Список переменных окружения. Понятная структура для следующей команды. SaaS можно развивать с нами, своей внутренней командой или другим техническим партнёром.
07 · Что мы не делаем · Анти-паттерны
Чего у нас не бывает в SaaS.
Несколько решений, которые встречаются в SaaS-проектах чаще, чем хотелось бы, и из-за которых продукт через год оказывается кандидатом на переписывание. У нас — нет.
- ×Не используем no-code как основу SaaS, если продукту нужны организации, роли, тарифы и развитие после запуска.
- ×Не откладываем модель организаций и доступов, если продукт изначально продаётся нескольким компаниям.
- ×Не усложняем архитектуру микросервисами без эксплуатационной причины.
- ×Не подключаем платёжный контур без ясной тарифной логики и подтверждённых требований к фискализации.
- ×Не держим код, доступы и документацию в закрытом контуре подрядчика.
- ×Не добавляем AI-функции в первую версию без отдельной оценки пользы, данных и риска.
08 · Как понять, нужен ли вам кастомный SaaS
Четыре варианта под одну задачу.
Не каждая задача требует кастомного SaaS. Перед стартом проверяем, не закрывается ли сценарий лендингом, готовым SaaS-инструментом или соседним направлением с более узким scope.
Лендинг или прототип
Подходит, если нужно быстро проверить интерес к идее без полноценного продукта.
Готовый SaaS-инструмент
Подходит, если ваш процесс уже закрывается существующим сервисом и собственная продуктовая логика не нужна.
Кастомный SaaS V1
Нужен, если вы строите собственный подписочный продукт с организациями, ролями, тарифами и планом развития после запуска.
Более широкая B2B-платформа
Нужна, если основная сложность — не подписка, а документы, процессы, интеграции, кабинеты или операционная логика.
09 · SaaS и подписочные продукты в портфолиоОткрыть полный архив→
Продукты, где первая версия строилась под рост.
Продукты, где первая версия строилась вокруг пользователей, ролей, тарифной логики, данных и дальнейшего развития. Подробности по архитектурным решениям — в самих кейсах.
B2B-платформа · Клиентский кабинет · Германия
Forschungsmittel.com
B2B-платформа для грантового консалтинга: публичный сайт, кабинет клиента и рабочее пространство команды. Из первой версии выросла в операционную платформу. Подробности — на странице кейса.
Открыть кейс→
Мульти-арендный SaaS · marketplace
Creator Marketing Platform
Мульти-арендный SaaS-маркетплейс с единым реестром услуг, движком цен и операторским инструментарием. Подробности по архитектурным решениям — на странице кейса.
Открыть кейс→
Подписочный SaaS · QR-сценарии
Web Page Generator
SaaS для динамических QR-связанных страниц. Подписочная модель, стабильные публичные URL, ограничение функций по тарифу на сервере, конструктор страниц с кастомизацией.
Открыть кейс→
Внутренний AI-инструмент H-Studio
Lead Lab
Внутренний AI-инструмент H-Studio с человеком в процессе. Архитектура с границами под контролем оператора и журналом AI-операций. Внутренний референс — не клиентский кейс. AI-сценарии подробнее — в направлении AI и автоматизация.
Открыть кейс→FAQ · Восемь вопросов основателя
Выбор между общей схемой с tenant_id, отдельной schema или отдельной базой зависит от требований к изоляции, стоимости эксплуатации, restore-сценариев, отчётности и договорных обязательств перед клиентами — а не от ярлыка «SMB» или «enterprise». Подбираем на архитектурном спринте под фактическую модель работы.
Можно — если первоначальная архитектура учитывает, в какую сторону продукт будет расти. Если продукт рассчитан на несколько клиентских организаций, модель изоляции данных и тарифную логику проектируем на старте, чтобы расширение не превращалось в переписывание. Для enterprise-пилотов с одним клиентом возможна другая модель.
Регистрация и вход с организациями и ролями, основной пользовательский сценарий продукта, тарифная логика и ограничения функций, платёжный контур — если он нужен запуску, админ-панель оператора с поиском, фильтрами и ручными операциями, базовые события продукта (регистрация, активация, ключевое действие, переход на оплату), мониторинг, резервные копии и документация для дальнейшего развития.
Для российского платёжного контура рассматриваем ЮKassa, интернет-эквайринг Т-Бизнеса и поддерживаемые сценарии оплаты через СБП — в зависимости от модели подписки, повторных списаний, возвратов и требований к чекам. Мы реализуем техническую часть: тарифную модель, ограничение функций, webhook-обработку событий и журнал платежей. Фискализацию, применимость 54-ФЗ и состав данных для чеков подтверждает бухгалтер клиента.
Для продуктов, обрабатывающих персональные данные граждан РФ, инфраструктурную схему проектируем с российским контуром первичного хранения данных. Состав и юридическая оценка обрабатываемых ПД, состав согласий и допустимая трансграничная передача подтверждаются профильным специалистом клиента. Международная инфраструктура рассматривается отдельно для допустимых сценариев и зарубежных рынков.
Международный платёжный контур оценивается отдельно под юридическую структуру продукта и доступность провайдера в нужной юрисдикции. Это не базовая часть страницы для российской аудитории и не подразумевается «по умолчанию» — конкретная схема и состав сценариев фиксируются под проект.
GitHub-репозиторий клиента, инфраструктурные доступы, документация архитектуры и схемы интеграций, runbook по типовым операциям, инструкции по деплою и переменным окружения. Продолжать развитие можно с нами в формате «Развитие и поддержка» или с другой технической командой.
Да — формат «Стабилизация существующего SaaS», 4–12 недель. Архитектурное ревью, план рефакторинга, корректировка модели изоляции данных и починка платёжного контура — без полного переписывания, где это возможно.
Дальше · Следующий шаг
Соберём первую версию SaaS,
которую можно запускать и развивать дальше.
Определим организации, роли, тарифную логику, основной пользовательский сценарий, платёжный контур и границы первой версии. Начать можно с архитектурного спринта или сразу обсудить SaaS V1.
Студия
H-Studio
Senior-поставка · Москва · Россия
Контакт
Офис
ул. Октябрьская д. 80 стр. 6
117593 Москва