Разрабатываем commerce-системы, когда бизнесу нужны договорные цены, кабинеты покупателей, сложный каталог, интеграции с учётными системами, нестандартные заказы или безопасная миграция с готовой платформы.
Готовый магазин может остаться правильным выбором для стандартной торговли. Кастом нужен, когда логика продаж является частью бизнеса: договорные цены, сложный каталог, заказные процессы, кабинеты покупателей или интеграции с учётными системами.
От 800 000 ₽. Первая версия обычно 8–16 недель.
К нам приходят, когда каталог, цены, заказы или интеграции больше не укладываются в готовую storefront-модель.
У товаров, услуг или комплектов есть сложные атрибуты, совместимость, варианты, договорные цены, доступность, документы или разные правила показа для разных клиентов. Мы проектируем структурированную модель каталога, фильтры, поиск, админ-панель и стабильную SEO-структуру.
Заявки и заказы передаются между сайтом, менеджерами, CRM и учётной системой вручную. Статусы расходятся, ошибки находят поздно, клиент не видит актуальное состояние заказа. Мы строим заказный процесс, панель команды и интеграционный слой с понятными источниками данных.
Розничный клиент покупает сразу, а корпоративному покупателю нужны договорные цены, заявки, счета, документы, повторные заказы, лимиты или согласования. Мы проектируем разные сценарии внутри одной commerce-системы, если это действительно нужно бизнес-модели.
Каталог, URL-структура, интеграции или процесс заказов больше не удаётся развивать без обходных решений. Мы оцениваем текущую систему, проектируем новую архитектуру, переносим необходимые данные и готовим миграцию каталога и индексируемых страниц с картой редиректов и контролем SEO-рисков.
В каждом типе фиксируем модель продаж, роли пользователей, заказный процесс и необходимые интеграции до старта разработки.
Для оптовых клиентов, дилеров, партнёров и корпоративных покупателей: каталог, фильтры, договорные цены, заявки или заказы, счета и документы, повторные заказы, кабинет покупателя и рабочая панель менеджеров. Подходит для дистрибуции, оптовых поставщиков, производителей, дилерских сетей и корпоративных закупок.
Для бизнеса, где розничные и корпоративные покупатели работают по разным правилам: публичные цены для B2C, договорные условия для B2B, разные способы оформления заказа, кабинеты компаний, документы и согласования. Подходит для производителей с розничным и оптовым каналом, брендов с дилерами, поставщиков с корпоративными контрактами и сервисов с публичной и договорной продажей.
Для проектов, где товар или предложение нельзя описать простой карточкой: комплекты, совместимые компоненты, конфигурируемые позиции, объёмные скидки, клиентские прайс-листы, региональные условия и нестандартный порядок оформления заказа.
Для существующих магазинов и B2B-каталогов: интеграции с CRM, 1С, складом, доставкой и платёжным контуром; перенос каталога и страниц на новую архитектуру; карта редиректов; контроль данных и SEO-рисков при запуске.
Готовая commerce-платформа подходит, если процесс стандартный: каталог, корзина, оплата, доставка и базовые интеграции. Гибрид подходит, если готовый storefront остаётся, а отдельный B2B-кабинет или интеграционный слой закрывает уникальную часть процесса. Custom нужен, если договорные цены, роли, каталог-логика, заказы или интеграции являются частью конкурентного преимущества.
Для первой версии реализуем только роли, которые участвуют в реальной продаже: покупатель, корпоративный клиент, менеджер или администратор. Кабинеты поставщиков, партнёров и дополнительные процессы добавляем только если они нужны бизнес-модели первой версии, а не как гипотетический запас на будущее.
Если каталог в основном контентный, CMS может быть достаточной. Если цены, доступность, варианты, документы, роли и заказы зависят от бизнес-правил, каталог проектируем как структурированные данные с рабочей админ-панелью. Маркетинговые страницы при этом могут управляться отдельно через CMS.
Шесть направлений работы, которые проектируются до сборки. Конкретный объём каждого — под бизнес-модель.
Структурированные позиции, категории, атрибуты, фильтры, поиск и SEO-страницы там, где они нужны органическому спросу.
Публичные цены, договорные цены, скидки, коммерческие условия или заявки на расчёт — по модели бизнеса.
Корзина, заявка или заказ, статусы обработки, действия менеджеров, уведомления и история изменений.
История заказов и заявок, документы, повторные обращения, сохранённые позиции и корпоративные условия — если это нужно B2B-сценарию.
Управление каталогом, заявками, заказами, статусами, ценами и ручными операциями без обращения к разработчику.
CRM, учётные системы, склад и платежи — по необходимости. Код, документация, доступы и схема запуска остаются у клиента.
Можно начать с архитектурного спринта, сфокусированной первой версии, миграции или интеграционного слоя. Финальная оценка зависит от каталог-логики, ролей, заказного процесса и интеграций.
Разбор модели продаж, каталога, ролей, заказного процесса, источников данных, интеграций и границ первой версии.
Commerce-платформа для оптовых или корпоративных продаж: каталог, заявки или заказы, кабинет покупателя, рабочая панель команды и необходимые интеграции.
Для бизнеса, где нужны разные сценарии B2B и B2C, сложная price-логика, документы, несколько рабочих ролей и более глубокий интеграционный контур.
Для бизнеса, который переносит каталог, страницы и процессы со старой платформы на новую архитектуру. Отдельно оцениваем данные, URL-структуру, редиректы, интеграции и риски запуска.
Для существующего commerce-проекта, где новая платформа не нужна, но обмен между сайтом, CRM, учётной системой, складом или платёжным контуром нестабилен.
Та же команда после запуска: новые функции, интеграции, мониторинг, улучшение заказных сценариев и развитие commerce-платформы.
Если цены, доступность, документы и правила заказа зависят от клиента или контекста, каталог проектируется как часть системы, а не как набор CMS-полей.
Правила оформления, обработки и изменения заказа не должны зависеть от набора кнопок в интерфейсе. Процесс проектируется так, чтобы команда могла управлять им через рабочую панель.
До разработки фиксируем, где живут товары, цены, клиенты, заказы и оплаты; какие данные синхронизируются и как обрабатываются ошибки внешних систем.
Если существующая платформа уже индексируется, новая архитектура проектируется с учётом URL, редиректов, метаданных, категорий и посадочных страниц.
Репозиторий, документация, доступы и схема запуска передаются клиенту. Развивать платформу можно с H-Studio или другой командой.
E-commerce платформы — не для каждой задачи. Если ваш сценарий ближе к одному из ниже — скажем об этом до начала разработки и подскажем подходящее направление.
Несколько решений, которые часто создают проблемы в commerce-проектах. У нас — нет.
Каждый — реальный production-проект. Подробности по архитектуре каталога, заказного процесса и интеграциям — в самих кейсах.
Платформа с единым реестром услуг и движком цен, асинхронной синхронизацией поставщиков, идемпотентными платежами и возвратами. Operator-grade админ-панель для управления каталогом и операциями. Стек: Java/Spring, Next.js, PostgreSQL.
Открыть кейс→
Платформа гибких офисов со структурированным каталогом локаций и объектов, кастомной admin-CMS, inquiry-flow и операционной моделью для команды. Архитектура для нескольких рынков. Стек: Next.js, TypeScript, Supabase.
Открыть кейс→
B2B-платформа с многоступенчатым процессом от заявки до закрытия мандата: документооборот, состояние биллинга, журнал действий, кабинеты клиентов и команды. Стек: Next.js, TypeScript, Neon/PostgreSQL.
Открыть кейс→
SaaS-платформа с подписочной коммерцией: тарифные планы, пробные периоды, изменение тарифа, ограничение функций на сервере. Пример подписочного биллинга — не товарного e-commerce. Стек: Next.js, TypeScript, Supabase.
Открыть кейс→Готовая commerce-платформа подходит для стандартного каталога, корзины, оплаты и доставки. Кастомная разработка нужна, когда бизнесу важны договорные цены, сложная структура каталога, разные сценарии B2B и B2C, заказные процессы, кабинет покупателя или интеграции, которые являются частью операционной модели.
Да — это один из основных сценариев. Реализуем персональные цены по роли клиента и сегменту, объёмные скидки, специальные коммерческие условия, повторные заказы по шаблонам, согласования и approval-процессы. Конкретная модель цен и условий фиксируется на архитектурном спринте до старта разработки.
Да, если это действительно нужно бизнес-модели. Публичные цены и быстрый чекаут для розницы, договорные условия, документы и согласования для корпоративных клиентов. Разные кабинеты и роли реализуются в одной системе с явными границами.
Да. 1С (через REST API или OData) для товаров, остатков, заказов и бухгалтерских документов; CRM (amoCRM, Битрикс24, HubSpot, кастомные) через webhooks и API; складские системы и платёжные провайдеры — по необходимости. Источник истины по каждому потоку данных фиксируется на архитектурном спринте.
Да — формат «Commerce migration» (от 500 000 ₽). Делаем аудит текущей платформы, карту каталога и данных, карту индексируемых URL и редиректов, перенос согласованного контента и проверку технического SEO. Подробнее по технической стороне миграции — на странице SEO-миграции.
Мы не обещаем сохранение текущих позиций. Поисковые системы самостоятельно переобходят и переоценивают страницы после изменений. Наша задача — снизить технические риски: сохранить ценные URL там, где это возможно, корректно настроить redirect для изменяющихся адресов, перенести метаданные и проверить sitemap, canonical, внутренние ссылки и доступность ключевых страниц после запуска.
Если команда регулярно работает с каталогом, заявками, заказами, статусами или ценами — да. Рабочая панель проектируется как часть commerce-платформы под реальный процесс команды, чтобы операционные действия не требовали обращения к разработчику. Для самых простых случаев иногда достаточно админ-возможностей выбранной CMS.
От модели продаж (B2B, B2C, гибрид), сложности каталога и price-логики, числа ролей и сценариев, объёма интеграций с учётными системами и платёжным контуром, необходимости миграции существующих URL и данных. Точная смета фиксируется на архитектурном спринте — после определения первой версии.
На архитектурном спринте фиксируем модель продаж, структуру каталога, роли покупателей и команды, заказный процесс, интеграции и границы первой версии. Если задачу рациональнее закрыть готовым магазином или отдельной интеграцией, скажем об этом до начала разработки.
