Scenario · 01
“Идея и первые пользователи”
У вас есть продуктовая идея, первые интервью или ранние пользователи. Нужна первая рабочая версия SaaS с организациями, ролями, тарифной логикой и понятным планом развития после запуска.
Направление · SaaS
Первая версия B2B SaaS с согласованным scope.
Первая рабочая версия подписочного продукта для основателей и растущих команд: организации, роли, тарифная логика, платёжный контур, админ-панель и продакшен-запуск — с архитектурой, которую можно развивать после первых клиентов.
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-репозиторий, документация и доступы остаются у вас.
03 · Три ключевых архитектурных решения
Самые дорогие решения принимаются до старта.
- 01
Как изолировать данные клиентских организаций?
Для SaaS с несколькими организациями модель изоляции выбирается на старте. Общая схема с tenant_id обычно проще в эксплуатации и обновлениях. Отдельные схемы или отдельные базы рассматриваем, когда нужны усиленная изоляция, восстановление данных на уровне клиента или договорные требования заказчиков. Выбор зависит не от ярлыка SMB / enterprise, а от риска, стоимости эксплуатации и модели продаж.
- 02
Как устроить тарифы и платёжный контур?
Для российского продукта рассматриваем доступные платёжные решения, включая ЮKassa и интернет-эквайринг Т-Бизнеса. Реализуем тарифы, доступность функций, статусы оплаты, возвраты и обработку событий провайдера. Фискальную и налоговую модель подтверждает клиент со своим бухгалтером или консультантом. Международный платёжный контур оценивается отдельно под юридическое лицо и поддерживаемую провайдером юрисдикцию.
- 03
Стек: модульный монолит или отдельные сервисы?
Модульный монолит — вариант по умолчанию для первой версии: понятные доменные границы и простой деплой. Отдельные сервисы добавляем только там, где это оправдано независимым масштабированием, изоляцией данных, интеграционной нагрузкой или требованиями эксплуатации.
05 · Форматы работы
От первой версии до расширенного B2B-продукта.
Формат подбираем по стадии продукта, модели данных, платёжному контуру и внешним зависимостям. План и оценка появляются после проверки scope.
SaaS V1
SaaS V1
Первая рабочая версия подписочного продукта для первых пользователей и клиентов: организации, роли, тарифная логика, основной пользовательский сценарий, админ-панель, платёжный контур при необходимости, аналитика, мониторинг и передача.
├Оценка после определения scope┤
- Организации и роли
- Основной пользовательский сценарий
- Тарифная логика и ограничения функций
- Платёжный контур — если нужен запуску
- Админ-панель оператора
- Базовая аналитика и мониторинг
- Документация и передача
Расширенный B2B SaaS
Расширенный B2B SaaS
Для продуктов, где уже в первой версии нужны несколько типов клиентов, корпоративный доступ, интеграции, расширенное журналирование, более глубокая админ-панель и документация для технической проверки.
├после уточнения scope┤
- Всё из SaaS V1
- Расширенная ролевая модель
- SSO — если нужен корпоративным клиентам
- Интеграции с внешними системами
- Журнал чувствительных действий
- Расширенная админ-панель
- Документация для технической проверки
06 · Почему H-Studio для SaaS
Первая версия, которую можно развивать дальше.
- 01
Первая версия без технического тупика
SaaS может меняться после первых клиентов — это нормально. Мы проектируем первую версию так, чтобы продукт не пришлось срочно перестраивать только потому, что на старте не были продуманы организации, роли, тарифная логика, данные, админ-панель или критичные интеграции.
- 02
Организации, роли и тарифная модель — на старте
Если продукт рассчитан на несколько клиентских организаций и подписочную модель, решения по изоляции данных, правам доступа, тарифам и платёжному контуру принимаются до разработки ключевых сценариев. Не добавляем их как запоздалую надстройку после запуска.
- 03
Инженерный контекст сохраняется до запуска
Инженерный лид участвует в разборе задачи и сохраняет контекст ключевых решений по данным, ролям, тарифам, интеграциям и эксплуатации на следующих этапах.
- 04
Код, доступы и документация — у вас
Код в вашем GitHub. Архитектурная документация. Доступы ко всем сервисам. Схема деплоя. Список переменных окружения. Понятная структура для следующей команды. SaaS можно развивать с нами, своей внутренней командой или другим техническим партнёром.
07 · Как понять, нужен ли вам кастомный SaaS
Четыре варианта под одну задачу.
Не каждая задача требует кастомного SaaS. Перед стартом проверяем, не закрывается ли сценарий лендингом, готовым SaaS-инструментом или соседним направлением с более узким scope.
Лендинг или прототип
Подходит, если нужно быстро проверить интерес к идее без полноценного продукта.
Готовый SaaS-инструмент
Подходит, если ваш процесс уже закрывается существующим сервисом и собственная продуктовая логика не нужна.
Кастомный SaaS V1
Нужен, если вы строите собственный подписочный продукт с организациями, ролями, тарифами и планом развития после запуска.
Более широкая B2B-платформа
Нужна, если основная сложность — не подписка, а документы, процессы, интеграции, кабинеты или операционная логика.
08 · 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,
которую можно запускать и развивать дальше.
Определим организации, роли, тарифную логику, основной пользовательский сценарий, платёжный контур и границы первой версии. Предварительный разбор можно включить в проект или вынести в отдельный архитектурный этап для более сложной системы.
Студия
H-Studio
Senior-поставка · Москва · Россия
Контакт
Офис
ул. Октябрьская д. 80 стр. 6
117593 Москва