Wwebreboot

Услуги

B2B-кабинеты и SaaS под вашу модель продаж

Проектируем продукты, где есть организации, роли, тарифы и внешние системы. Права и границы данных закладываем в модель сразу. Собираем продукт под вашу продажу, а не универсальный конструктор «на все отрасли».

Кому подходит

  • Команды с B2B-моделью: кабинеты для клиентов, партнёров, франшизы или дистрибуции
  • Внутренний IT, которому нужен портал вместо таблиц, почты и доступа «у того, кто помнит»
  • Сервис, который уже продаётся, но внутренние процессы остаются в переписке и таблицах

Что делаем

Модель доступа

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

Изоляция данных

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

Операционный интерфейс

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

Биллинг и тарифы

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

API и интеграции

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

Наблюдаемость продукта

Логи с идентификаторами организации и пользователя, ошибки API, состояние очередей и базовые оповещения. Такой контекст сокращает время диагностики и помогает разбирать обращения пользователей.

Состав работ

  • Доменная модель: организация, роли, сущности, события, границы арендатора
  • Один сквозной сценарий до результата: приглашение, роль, ключевое действие, отчёт или счёт
  • Интерфейс оператора: поиск клиента, вход от его имени только по регламенту, журнал действий
  • Схема биллинга, если она в этапе: тариф, лимит, статус оплаты
  • Контракт API или вебхуков, если продукт открывается наружу
  • Политика данных: что храним, где, как выгрузить и удалить организацию
  • Стенд, миграции, доступы, инструкция по выкладке

Как связаны части решения

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

Контур B2B-продукта
flow

  1. 01Доступ

    • Организация
    • Роли
    • Приглашения

  2. 02Продукт

    • API
    • Бизнес-логика
    • Тарифы

  3. 03Контроль

    • Изоляция данных
    • Журнал действий
    • Интеграции

Стек

TypeScriptNode.jsPostgreSQLRedisNext.jsReactочередь задачOpenAPI

Этапы

  1. 01

    Доменная модель

    2–3 недели

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

    Приёмка: Схема модели и список сценариев первого этапа.

  2. 02

    Первый рабочий сценарий

    4–8 недель после модели

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

    Приёмка: Стенд, на котором роль проходит путь до результата.

  3. 03

    Остальной продукт этапа

    по составу

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

    Приёмка: Закрытый состав этапа на stage с миграциями.

  4. 04

    Выкладка и наблюдаемость

    1–3 недели

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

    Приёмка: Рабочее окружение передано заказчику вместе с журналом и инструкцией по инциденту.

Нормы и ограничения

RBAC, а не набор галочек на экране

Право проверяется на сервере по роли и организации. Скрытие элемента в интерфейсе не заменяет серверную проверку доступа.

Журнал действий

Журнал фиксирует приглашения, выгрузки и изменения тарифа. Он используется для аудита доступа и разбора инцидентов, но не заменяет остальные меры защиты персональных данных.

Идемпотентность платежей и вебхуков

Повтор уведомления от кассы или партнёра не должен создать второй счёт или вторую отгрузку. Ключ идемпотентности это стандарт платёжных и интеграционных API.

152-ФЗ и место хранения

Если система обрабатывает данные граждан РФ, до разработки фиксируем место хранения, состав обработчиков и процедуру удаления данных организации. Юридические основания и регламенты подтверждает заказчик.

Сроки

Первый рабочий сценарий с ролями и одной организацией обычно занимает 8–16 недель от старта проекта. После утверждения доменной модели разработка самого сценария занимает ориентировочно 4–8 недель. Точный срок зависит от интеграций и критериев приёмки.

Срок растёт, если:

  • Несколько типов организаций и разные прайсы на одну базу
  • Синхронизация с 1С, банком или отраслевой шиной без документированного контракта
  • Миграция с таблиц и почты, в которых нет устойчивого идентификатора клиента
  • Требование «сделать как у крупного западного SaaS» без своей модели продажи

Не входит

  • Готовый конструктор CRM / helpdesk / HR «как у лидеров рынка» за один этап
  • Сертификация SOC 2, ISO 27001 и penetration test как часть обычной разработки. Это отдельные работы
  • Продвижение продукта и отдел продаж
  • Поддержка существующей системы без исходного кода и доступа к базе данных

Результат

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

Вопросы направления

Можно ли запустить SaaS за месяц?+

За месяц можно собрать узкий сценарий и проверить гипотезу. Продукт с организациями, правами и биллингом за месяц не получается устойчивым. Это не особенность студии, так устроен объём.

Нужна ли мультиарендность сразу?+

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

Можно ли взять вас только на архитектуру?+

Да. Модель, границы сервисов, контракт API и критерии приёмки. Сборку тогда ведёт внутренняя команда по этой рамке.

Какой биллинг закладывать?+

Схема биллинга должна соответствовать модели продаж: договор и счёт, подписка, пользовательские места или объём. Для эквайринга предусматриваем сверку платежей и историю изменения тарифа.

Где должны жить данные?+

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

Что с безопасностью?+

База: серверные права, журнал, секреты вне репозитория, HTTPS, разделение админки. Аудит ИБ, багбаунти и формальные сертификаты это отдельные закупки со своим сроком.

Следующий шаг

Обсудить задачу

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

Оставить заявку