Взгляд CPO на дистрибуцию B2B-IT-продуктов и опыт построения SaaS-экосистемы
Рынок IT-продуктов давно не испытывает дефицита технологий. Мы умеем строить сложные сервисы, масштабировать инфраструктуру и писать качественный код.
При этом по-настоящему масштабных B2B-SaaS-продуктов по-прежнему немного.
На мой взгляд, причина почти всегда не в технологиях.
Как руководитель продукта я всё чаще сталкиваюсь с одной и той же системной проблемой — стоимостью выхода на рынок. Большинство IT-продуктов не умирают из-за плохой архитектуры или «не того стека». Они умирают потому, что не могут выйти за пределы своей компании, группы компаний, региона или страны.
К этому добавляется отсутствие профессиональных продаж, маркетинга и бюджета на них — и это, по моим наблюдениям, типичная ситуация для B2B-рынка, а не чья-то персональная ошибка.
Последние четыре года мы проектируем и развиваем продукт, который я изначально рассматриваю как SaaS-платформу и экосистему. Платформу, которая позволяет сторонним командам и вендорам упаковывать и продавать свои IT-продукты, не передавая исходный код и не теряя контроль над сервисами.
Исторически входной точкой для бизнеса стал коммерческий продукт «Биллинг» — платёжный шлюз и оркестратор с терминалом/кассой для B2B-клиентов. Он коммерчески успешен и понятен рынку, поэтому именно в него логично инвестировать в маркетинг и продажи.
Вопрос, который я хочу обсудить в этой статье, другой: останется ли написанная нами платформа просто B2B-продуктом — или может стать входом в модель дистрибуции в виде SaaS-маркетплейса?
Я сознательно пишу этот текст как гипотезу, а не как утверждение, и рассчитываю на критическое обсуждение.
Где в реальности болит у B2B-команд
В профессиональной среде принято много говорить об архитектуре и инфраструктуре. Это важно, но часто вторично по отношению к одному вопросу: сколько стоит превратить работающий сервис в продаваемый B2B‑продукт?
Если смотреть на B2B‑продукты класса back‑office, то чаще всего ломается не код.
Ломается экономика времени и денег на «обвязку» — эксплуатационный и платформенный слой, без которого продукт невозможно безопасно и массово использовать за пределами одной команды или компании.
Речь не о том, что каждому продукту нужен весь набор таких компонентов.
Речь о том, что в реальной эксплуатации почти всегда требуется значимая их часть:
управление организациями, пользователями, ролями и правами доступа;
аудит действий и журналирование;
биллинг и тарификация;
административный UI, который должен быть стабильным, предсказуемым и безопасным;
отчётность, статистика и дашборды;
локализация интерфейса при выходе за пределы одного рынка.
Каждый пункт по отдельности выглядит решаемым.
Но вместе они формируют платформенный слой, который почти не дифференцирует продукт, но существенно увеличивает time-to-market и стоимость выхода на рынок.
Это не теоретическое рассуждение.
В нескольких командах, с которыми мы общались и работали в рамках платформы, поддержка административного и эксплуатационного слоя по трудозатратам оказывалась сопоставимой с разработкой core-бизнес-логики сервиса.
И именно этот слой чаще всего становился узким местом: его сложно ускорить, трудно переиспользовать и почти невозможно показать заказчику как самостоятельную ценность.
Что под капотом: инфраструктура и безопасность как сервис
Поскольку мы предлагаем платформу как фундамент для чужого бизнеса, вопросы надежности перестают быть только нашими внутренними проблемами. Если падает платформа — останавливается бизнес вендоров.
Поэтому мы осознанно отказались от экзотики в пользу промышленных стандартов.
Технологически платформа — это классический cloud-native стек. Мы работаем в мультиклаудной среде, используя ресурсы гигантов вроде AWS и GCP для критически важных компонентов. Базы данных — стандартный Postgres, оркестрация — Kubernetes, ClickHouse — для статистических данных.
Архитектурно это система из десятков микросервисов, которую развивает и поддерживает команда из более чем 20 инженеров.
Почему эти цифры важны для потенциального партнера?
Для одиночного B2B-продукта содержание такого инфраструктурного штата и обеспечение подобного SLA на старте часто экономически нецелесообразно. Мы же, по сути, разделяем стоимость этой надежности и экспертизы между всеми участниками экосистемы. Процессы разработки и тестирования выстроены так, чтобы обновлять платформу быстро, но гарантировать стабильность для уже работающих сервисов.
Отдельно стоит сказать про безопасность. Так как исторически ядром системы является платежный продукт, мы не могли ограничиться «честным словом». Платформа сертифицирована по стандарту PCI DSS V4. Мы регулярно проходим внешние аудиты архитектуры и процессов. Для вендора это означает, что жесткие практики защиты данных и Compliance мы обеспечиваем «из коробки», снимая с него головную боль по прохождению подобных проверок с нуля.
В эту инфраструктурную обвязку было вложено много сил, и сегодня она работает как часы.
Какие модели дистрибуции существуют сегодня
Если упростить, на рынке можно выделить несколько устойчивых моделей — и каждая решает свою задачу.
Закрытые SaaS-продукты
Команда полностью владеет продуктом: кодом, UX, инфраструктурой и продажами.
Типичные примеры — Salesforce, ServiceNow.
Модель даёт максимальный контроль, но требует серьёзных инвестиций в масштабирование.
Плагин-экосистемы вокруг одного SaaS
Продукт живёт как расширение чужой платформы и полностью зависит от неё.
Например, Atlassian Marketplace или Shopify App Store.
Это снижает порог входа, но лишает продукт автономности.
API-маркетплейсы
Решают задачу распространения API, но не продукта целиком.
Примеры — RapidAPI, каталоги API в Postman.
API остаётся инструментом для разработчиков, а не готовым IT-продуктом.
Internal-tools и low-code платформы
Помогают быстро собирать интерфейсы для внутренних задач.
Например, Retool или Budibase.
Но почти не решают вопросы коммерции и дистрибуции.
Все эти модели работают — в своём контексте
Проблема возникает там, где продукту нужен независимый backend, полноценный back-office и коммерческий канал, но делать всё самостоятельно слишком дорого.
Идея продукта: какую незакрытую потребность мы пытаемся закрыть
Между «делать всё самому» и «встроиться в чужой монолит» остаётся зазор.
Есть команды, которые умеют делать сильные B2B-сервисы с реальной ценностью.
Но чтобы превратить такой сервис в продукт, им приходится каждый раз заново строить эксплуатационный контур и искать путь к рынку.
Наша гипотеза в том, что для части B2B-продуктов имеет смысл вынести повторяющийся эксплуатационный и коммерческий слой в общую SaaS-платформу, не забирая у вендора backend, данные и бизнес-логику.
Это не универсальная модель и не замена существующим подходам.
Она имеет смысл прежде всего для B2B и back-office решений, где ценность — в данных и процессах, а не в визуальной дифференциации интерфейса.
Как выглядит предлагаемая модель
В упрощён��ом виде модель такая:
вендор разрабатывает и эксплуатирует собственный backend в своей инфраструктуре;
бизнес-логика и данные полностью остаются у вендора;
платформа не исполняет бизнес-код вендора;
платформа предоставляет эксплуатационный и коммерческий контур:
административный UI, доступы, аудит, тарификацию, биллинг и канал дистрибуции;клиенты работают с продуктами через единую административную среду.
Это не плагин и не хостинг кода.
Это попытка стандартизировать back-office слой B2B-продуктов.
Экономическая модель и комиссии — отдельный и непростой вопрос.
В этой статье я сознательно не ухожу в детали, потому что формат обсуждения здесь — не про unit-экономику, а про применимость самой модели.
Важно лишь зафиксировать, что в предлагаемом подходе платформа зарабатывает на дистрибуции и эксплуатации, а не на владении кодом или данными вендоров.
Откуда появился «Биллинг» и почему бизнес видит продукт именно так
Изначально бизнес-задача была прикладной — построить финансовый B2B-продукт для управления платёжными решениями: шлюз, оркестрацию и терминал/кассу.
Чтобы такой продукт был гибким, пришлось создавать дополнительные сервисы: управление доступами, тарификацию, отчётность, дашборды, локализацию, риски, KYC и поддержку.
Так вокруг биллинга естественным образом выросла платформа.
При этом для бизнеса биллинг остаётся якорным продуктом — потому что он напрямую монетизируется и понятен рынку.
Вопрос не в том, плохо это или хорошо.
Вопрос в том, останется ли платформа только биллингом или станет основой для дистрибуции других B2B-продуктов?
Самый спорный момент: административный UI и lock-in
В описываемой модели платформа берёт на себя административный интерфейс продукта.
Интерфейс задаётся в виде конфигурации (JSON), которая описывает страницы, элементы управления и их связь с API вендора. Платформа по этой конфигурации автоматически собирает рабочий back-office интерфейс.
Важно зафиксировать: это форма vendor lock-in.
Зависимость возникает не на уровне backend-кода или данных, а на уровне административного UI и его реализации внутри платформы.
Мы считаем этот компромисс допустимым для части B2B-сценариев, потому что речь идёт об интерфейсе, функции которого включают:
управление организациями и пользователями;
настройку ролей и прав доступа;
аудит и логирование;
конфигурацию продуктов и тарифов;
эксплуатационные и системные настройки.
При выходе с платформы backend и данные остаются у вендора, API не меняется.
Да, это дополнительные затраты, но ограниченные и заранее понятные, а не скрытая архитектурная ловушка.
Почему утилитарный UI — часть архитектуры
Поскольку платформа берёт на себя административный интерфейс продуктов, этот UI должен быть не витриной, а рабочим инструментом.
Мы ориентировались на подходы, используемые в решениях уровня IBM Cloud и дизайн-системе Carbon Design System — не как на бренды, а как на язык проектирования утилитарных back-office интерфейсов, рассчитанных на долгую и стабильную эксплуатацию.
Главный страх вендора — не код, а клиент
На практике вендоров больше всего беспокоит:
потеря прямых отношений с клиентом;
контроль над тарифами;
зависимость от правил платформы;
риск конфликта интересов.
Любая экосистема ломается не на технологии, а на непроговорённых правилах.
Минимально в таких правилах должны быть зафиксированы принципы владения клиентами, ограничения на конкуренцию платформы с вендорами (non-compete), прозрачность комиссий и понятная стратегия выхода с переносимостью.
Без этого любые разговоры о «vendor-friendly платформе» остаются декларацией, даже при корректной архитектуре.
Что именно я хочу проверить этой публикацией
Я не пытаюсь доказать, что эта модель верна или универсальна.
Я хочу проверить несколько вопросов:
Есть ли B2B-команды, которым дорого и долго строить эксплуатационный контур?
Какие условия необходимы, чтобы вендоры доверяли платформе?
Где границы применимости такой модели?
Вместо заключения
Этот текст — не манифест и не вердикт.
Реакция сообщества для меня — дополнительный контекст, который требует фильтрации, но помогает увидеть риски и слепые зоны гипотезы.
Именно ради этого контекста я и публикую эту статью. Спасибо за конструктивную критику.
