TrendBox
B2B-платформа оптового дистрибьютора напитков с заявками вместо онлайн-оплаты
Проблема
Дистрибьютор ведёт опт напитков вручную: заявки по телефону и в мессенджерах, остатки — в 1С, прайсы — в Excel-файлах, которые устаревают быстрее, чем доходят до клиента. При этом дистанционная продажа алкоголя в РФ юридически ограничена: кнопку «Купить сейчас» с онлайн-оплатой на сайте не построишь, даже если очень хочется.
Задача
Спроектировать MVP-витрину, которая закрывает воронку «увидел товар → собрал заявку → получил счёт от менеджера» без единой кнопки оплаты на сайте — и при этом не выглядит как урезанная версия обычного интернет-магазина.
Решение
Классическая e-commerce-механика витрины — каталог, фильтры, карточка товара — переведена в RFQ-логику (Request for Quote): покупатель собирает корзину-заявку, она уходит менеджеру, а счёт и отгрузка происходят вне сайта. Юридическое ограничение стало не багом UX, а осознанным продуктовым решением, зафиксированным отдельной ADR-записью.
Личный кабинет B2B-клиента показывает то, что реально важно юрлицу: статус заявок, оптовые цены (видны только активированным юрлицам) и реквизиты компании — а не «избранное» и «историю просмотров», как в обычном интернет-магазине.
Админ-панель заточена не под типовую CRM, а под конкретные боли дистрибьютора: импорт каталога и остатков прямо из Excel-выгрузок 1С — без ручного набора 750+ позиций, настройка слайдера на главной, работа с юрлицами и заявками.
Отдельный блок — Telegram: авторизация клиентов, бот-уведомления о статусе заявки и инструмент массовой рассылки прямо из админки — без email-рассылок, которые B2B-клиенты из мессенджеров всё равно не открывают.
Мой вклад
Спроектировал архитектуру целиком: разделение витрины и коммерческого бэкенда, схему модулей Medusa (заявки, баннеры, юрлица, импорт), RFQ-флоу вместо оплаты, интеграцию с Telegram Bot API. Веду разработку витрины и бэкенда сам, от ADR до продакшен-кода.
Архитектура
- Витрина (apps/storefront) — Next.js 15 App Router, полностью отделена от коммерческого бэкенда и общается с ним через API Medusa.
- Коммерция (apps/backend) — headless Medusa.js v2 с собственными модулями: заявки (RFQ), баннеры, юрлица, импорт каталога — вместо форка типового e-commerce-ядра под чужую логику.
- Импорт данных (packages/importer) — отдельный воркспейс, превращающий Excel-выгрузки 1С в карточки товаров и остатки без ручного ввода.
- Каждое архитектурное решение фиксируется ADR-записью в SPECS/decisions, бизнес-правила — в SPECS/domain: любой человек или нейросеть, открыв репозиторий, восстанавливает контекст решений, а не только код.
Что было непросто
Продать RFQ как полноценный e-commerce-опыт
Убрать кнопку оплаты — не значит убрать ощущение покупки. Пришлось спроектировать корзину-заявку так, чтобы она вела себя как обычный чекаут (счётчики, итоговая сумма, статус) — а не как форма обратной связи с прикреплённым файлом.
750+ товаров без ручного ввода
Каталог и остатки дистрибьютора живут в 1С и Excel, а не в API. Импортёр должен был превращать неструктурированные выгрузки в чистые карточки товаров — с картинками, категориями и вариантами — без потери данных на каждой новой выгрузке.
152-ФЗ и юридические ограничения как часть архитектуры
Хостинг только в РФ, хранение персональных данных, отсутствие дистанционной продажи алкоголя — эти ограничения решались на уровне архитектуры и инфраструктуры с самого начала, а не патчились в конце.
Результат
MVP в активной разработке: каталог, витрина, личный кабинет и админ-панель реализованы и работают на тестовом стенде. Дисциплина ADR и доменных спецификаций с первого дня означает, что публичный запуск не потребует «раскопок» в собственных решениях многомесячной давности.
Как это выглядит
