BAZA — маркетплейс оптовых поставщиков в мессенджере MAX
Строим с нуля B2C в российском мессенджере : покупатель получает прямой доступ к оптовым поставщикам вместо того, чтобы переплачивать 15–25% комиссии маркетплейсов. Подписка с , trial 3 дня, реферальная программа. Full-stack: FastAPI + React + PostgreSQL + Redis + MinIO, собственный , 12 агентов Claude в оркестре.
Под NDA
MAX Mini App + Bot
Full-stack, свой VPS
Апрель 2026
MVP в разработке
Кейс за 60 секунд
Прямой доступ к оптовикам в мессенджере MAX — покупатель не переплачивает 15–25% комиссии маркетплейсов.
Клиент и боль
B2C-продукт в российском e-commerce (клиент под NDA). Покупатель на WB и Ozon переплачивает 15–25% комиссии маркетплейса, но не умеет выйти на оптового поставщика напрямую — а поставщик не умеет работать с розничным трафиком.
Что построили
Mini App в MAX (приложение внутри чата) + админка + бот + бэкенд на FastAPI с PostgreSQL FTS (русскоязычный поиск по базе), Redis-кэшем, MinIO-хранилищем. 12 AI-агентов Claude в оркестре по spec-driven процессу: сначала требования, потом код, на каждом шаге ревью.
Кому подойдёт
Продуктам, которым нужен Mini App в MAX или Telegram с подпиской, оплатой и собственной инфрой — без вендор-лока конструкторов.
Задача
Убрать лишнего посредника между покупателем и производителем
Покупатель заходит на WB или Ozon, покупает товар и переплачивает 15–25% — это комиссия маркетплейса, зашитая в цене. При этом большинство товаров можно купить у поставщика напрямую, даже от одной штуки, — но покупатель не знает, как их найти, а поставщик не умеет работать с розничным B2C-трафиком.
BAZA — B2C Mini App внутри мессенджера MAX: пользователь ищет товар, получает список поставщиков с ценами ниже маркетплейса и связывается с ними напрямую. Монетизация — ежемесячная подписка с 3-дневным trial и реферальной программой (+7 дней за приведённого пользователя). Оплата — через ЮKassa.
Задача была не «сделать приложение», а построить полноценный SaaS: фронт для покупателя, админка для загрузки поставщиков Excel-пачками, бот для уведомлений, бэкенд с подписками, поиском, избранным, отзывами, импортом. Всё это на собственной инфраструктуре, без привязки к no-code и конструкторам.
Как это выглядит
Живой Mini App внутри мессенджера MAX
Это не макет из Figma и не слайд из презентации. Скриншоты сделаны прямо из MAX на этапе внутренней сборки: онбординг и главный экран уже отвечают на реальные запросы к нашему бэкенду.
В цифрах
Масштаб и техника
Архитектура
Четыре приложения в одном репозитории
Это не один фронт и «какой-то бэкенд», а четыре самостоятельных приложения с общим деплоем, общей базой и общим дизайн-языком. Каждое решает свою задачу и работает независимо от остальных.
Mini App (фронтенд для покупателя)
React + TypeScript + Vite + Tailwind + Zustand + TanStack Query. HashRouter — потому что контейнеры Mini App в мессенджере не дружат с History API. — в Zustand store, не в localStorage: модель XSS в Mini App-вебвью другая, и перезагрузка в мессенджере безопаснее держит состояние в памяти.
Backend (FastAPI + PostgreSQL + Redis + MinIO + Celery)
FastAPI с async SQLAlchemy и asyncpg. 15 таблиц с gin-индексом по search_vector и конфигом russian — без этого на русском работает хуже LIKE. Пагинация только cursor-based: deep offset на сотнях тысяч записей убивает Postgres. кэширует категории, баннеры и статус подписки. — для Excel-файлов импорта.
Admin Panel (отдельный фронт)
Второй Vite-проект с теми же токенами дизайна, но BrowserRouter и JWT в localStorage — это админ в обычном браузере, а не в мессенджере. 8 разделов: дашборд, пользователи, поставщики, товары, категории, баннеры, рассылки, финансы. Логин/пароль из .env, дальше — JWT.
MAX-бот (maxapi + Celery)
В dev — polling, в проде — через nginx с проверкой X-Max-Bot-Api-Secret. Webhook всегда возвращает 200 за ≤100 мс, обработка уходит в -очередь: мессенджеры банят медленные вебхуки. Одновременно polling и webhook — запрещено на уровне деплоя.
Методология
Spec-driven разработка, а не «попросил нейронку написать»
Разница между «вайб-кодингом» и инженерной разработкой с AI — в процессе. Код появляется не после вопроса «напиши мне приложение», а после четырёх слоёв документов и ревью. На каждом слое можно остановиться и поправить направление до того, как переписывать код.
User Spec (русский)
Сначала описываем ЧТО и ЗАЧЕМ: бизнес-логика, роли, сценарии, acceptance criteria. Русский — чтобы с продуктом и заказчиком можно было пройти документ слово за словом. Это не ТЗ в вакууме, а чек-лист, по которому мы потом проверяем каждую выкатку.
Tech Spec (английский)
Следующий слой — КАК реализовать. Архитектура, контракты API, схема БД, decisions log. Английский — потому что это язык кода и PR-комментариев, и переводить термины между документами нет смысла. Каждое решение зафиксировано: почему FTS на Postgres, а не Elasticsearch. Почему MinIO, а не S3 в облаке.
Декомпозиция на задачи
Tech Spec режется на атомарные задачи с -якорями — тест пишется до кода. У каждой задачи — список reviewers и чек-лист приёмки. Ни одна задача не уходит в работу без ревью самого файла задачи: это защита от галлюцинаций и размытых требований.
Quality gates между этапами
После каждого слоя — code-review по 11 измерениям, security-audit по , ревью тестов, валидация полноты относительно исходного user-spec. Между этапами — ручная проверка в браузере, в MAX через ngrok, или в curl. Агент не переходит дальше, пока гейт не зелёный.
AI-стек
Команда агентов Claude с разделением ролей
Мы работаем на стеке Anthropic: как CLI-оркестратор, для кастомных агентов, для внешних интеграций. Это не один чат, куда складывается всё подряд, — а команда специализированных агентов, каждый со своим набором инструментов и правами.
Claude Code CLI как оркестратор
Главный чат — это team lead: читает доки, распределяет работу по агентам, проверяет отчёты. Никакого «сделай всё сам и выкати в прод». Каждый агент делает только свой слой — backend, фронт, админка, инфра, тесты, ревью — и возвращает отчёт с артефактами (логи, curl-ответы, прогоны pytest).
Claude Agent SDK для кастомных агентов
Под каждую типовую роль — свой агент с ограниченным набором инструментов: code-reviewer, security-auditor, test-reviewer, tech-spec-validator, reality-checker. Они проверяют работу друг друга. Это не один чат, где всё мешается — это команда с ролями и правами доступа к инструментам.
Opus для архитектуры, Sonnet для исполнения
Сложные архитектурные решения и критический код — Claude Opus. Рутинное исполнение, ревью, валидации — Sonnet. Такое разделение снижает стоимость разработки, не теряя в качестве: Opus думает там, где цена ошибки высокая.
MCP-серверы для внешних интеграций
Playwright MCP — чтобы агенты могли открывать браузер и проверять собранный UI. Context mode — собственная индексация документации. Это инженерная инфраструктура вокруг модели, а не просто чат с LLM.
Инфраструктура
Прод-grade инфра с первого дня
Обычно инфра к MVP — это «запустили docker-compose, оно работает». Мы сразу собрали инфру так, как если бы завтра шли в нагрузку и в модерацию: , лимиты памяти, бэкапы с проверкой целостности, с автопродлением, правильная ротация логов.
Docker-контейнеры с pinned sha256 digests
postgres:15-alpine, redis:7-alpine, minio, nginx:alpine, backend — все пять контейнеров пришпилены к конкретному sha256-digest, а не к тегу latest. Иначе апдейт базового образа в нужный момент сломает прод.
mem_limit на каждом контейнере
postgres 384M, redis 200M, minio 256M, backend 512M, nginx 128M. Без лимитов один сервис в OOM съедает память под остальными. С лимитами проблема видна локально, а не каскадом.
Бэкапы с flock и sha256
Ежедневный cron-бэкап Postgres (db + globals + env) и MinIO (tar). Рядом с каждым — sha256-чек-сумма, чтобы проверить целостность перед восстановлением. flock — чтобы два параллельных запуска cron не порезали друг другу dump.
Let's Encrypt с автопродлением
TLS-сертификат выдан certbot, автопродление через certbot.timer. Публичные health-чеки /api/health возвращают 200. HTTPS работает, HTTP редиректит на HTTPS 301. Всё проверяется одним curl.
Логи, swap, logrotate
JSON-file драйвер логов с ротацией 10M × 3 файла. Swap 1G c swappiness=10 — на случай пиковой нагрузки, но без постоянной работы в свопе. Инфра-контейнеры получают только свои переменные, а не весь .env.
Секреты отдельно от репо
.env с 18 переменными, права 600, не лежит в git. Инфра-пароли ротированы на старте — начальные креды не продержались ни одного коммита. GitHub используется только как бэкап исходников, без CI-доступа к проду.
Инженерные решения
Мелочи, которые не появляются от одного промпта
Каждое из решений ниже мы приняли и зафиксировали в decisions log до того, как написать соответствующую строчку кода. Эти вещи — результат опыта с живыми ботами, вебхуками и подписками, а не дефолтная обёртка генератора.
Webhook ≤100 мс → Celery
Любой webhook в мессенджере — это контракт «ответь за миллисекунды, иначе я тебя выключу». Внутри хендлера только валидация и постановка в очередь, тяжёлая логика уходит в Celery-воркер. Без этого бот банится платформой через пару часов прода.
Двойная проверка подписки в middleware
Middleware пропускает, если trial_ends_at > NOW() ИЛИ subscription_expires_at > NOW(). Одной переменной недостаточно: пользователь в триале сегодня, завтра платит, послезавтра продлевает. Пропустить одну из веток — и платящий клиент теряет доступ на сутки.
Cursor-based пагинация, не offset
На сотнях тысяч карточек deep offset заставляет Postgres каждый раз сканировать всё до текущей страницы. Cursor по индексу — O(log n) и стабильное время ответа. На старте разница не видна, к 100k записей — отвал.
PostgreSQL FTS с конфигом russian + gin
Без конфига russian словоформы «поставщик / поставщики / поставщиков» не склеиваются. Без gin-индекса по search_vector каждый запрос — последовательный скан. С правильной связкой поиск по русскому работает как надо с первого релиза.
JWT в Zustand, а не в localStorage
В контейнере Mini App модель XSS и жизненный цикл вкладки отличаются от обычного браузера. Хранить токен в памяти через Zustand-store — безопаснее и проще контролировать инвалидацию. Для админки в обычном браузере — localStorage, там контекст другой.
HashRouter в Mini App, BrowserRouter в админке
Mini App-контейнеры часто ломают History API — страница после навигации возвращается на корень при перезагрузке. HashRouter даёт стабильные URL внутри вебвью. Админка — обычный браузер, там BrowserRouter без нюансов.
Rate-limits по классам эндпоинтов
slowapi с разными политиками: auth 10/min, products 120/min, search 60/min, reviews 5/hour. — это не просто «защита от атак»: разные эндпоинты имеют разную стоимость и разный паттерн абуза. Отзывы 5/час — защита от накруток, search 60/мин — достаточно для нормального UX.
CSS-переменные темы, --viewport-height
Хардкод цветов через пару месяцев превращается в ад при ребрендинге. Все токены — через CSS-переменные. Для высоты вьюпорта — не 100vh (ломается на мобильных с динамическим UI браузера), а --viewport-height от MAX SDK. Кастомные модалки вместо alert/confirm — нативные модалки в Mini App нельзя стилизовать.
Кэш Redis с осмысленным TTL
Категории — TTL 15 минут (редко меняются, читаются всеми), баннеры — 5 минут (меняются чаще), статус подписки пользователя — 1 минута (критично для прохождения middleware). Без кэша каждая загрузка Mini App — 5+ запросов в Postgres.
Импорт поставщиков через очередь
Excel-файл кидается в MinIO, создаётся запись в import_logs, Celery подхватывает и парсит асинхронно. Админ не ждёт в окне «загрузка 800 строк», а видит прогресс и результат с ошибками по строкам. Если парсинг упал — файл остаётся в MinIO, повторяем без повторной загрузки.
Стек
Свой full-stack, а не конструктор Mini App
No-code и конструкторы Mini App
Вендор-лок, ограничения по интеграциям, чужая аналитика, нет контроля над поиском, кэшем, rate-limits. Подписочная модель с ЮKassa и реферальной программой — нереализуема без костылей. Сменить подрядчика — значит начать с нуля.
FastAPI + React + Postgres + Redis + MinIO
Полный контроль над поиском (FTS с конфигом russian), кэшем (Redis с управляемым TTL), интеграциями (MAX API, ЮKassa, S3-совместимый MinIO). Исходники и инфра полностью у клиента на собственном VPS. Сменить подрядчика можно без миграции.
Что получает бизнес
Результат такого подхода к разработке
Полноценный full-stack SaaS, а не лендинг
Это не страница-визитка: 4 приложения в одном репо, собственная база, собственный VPS, собственный деплой. Разработка ведётся как прод-сервис с первого дня — healthcheck'и, бэкапы, rate-limits, TLS.
Исходники и инфра — полностью на VPS клиента
Никаких no-code конструкторов, никаких SaaS-подписок за каждый блок, никакой блокировки подрядчиком. Домен, база, файлы, код — всё лежит на одном сервере под управлением клиента. Можно сменить подрядчика без миграции.
Документация для подхвата другой командой
Архитектура, decisions log, бизнес-логика, deploy-гайд — всё в отдельных .md-файлах в репо. Если завтра на проект садится другой разработчик, у него есть полный контекст без «позвони Яше, он помнит». Это страховка от bus factor.
Каждое архитектурное решение объяснено
В DECISIONS.md зафиксировано не только что выбрано, но и почему: FTS на Postgres вместо Elasticsearch, MinIO вместо облачного S3, Celery вместо RQ. Через полгода никто не спросит «зачем так сделали» — ответ уже в репо.
Быстрый и предсказуемый ритм разработки
Spec-driven пайплайн с ревью на каждом шаге даёт предсказуемость: задача → код → ревью → мёрдж за день-два, а не «месяц без видимого результата». Клиент видит прогресс в виде работающих экранов, а не в виде сообщений «ещё чуть-чуть».
Готовность к модерации MAX и запуску подписок
Инфра, HTTPS, логи, бэкапы, privacy-обвязка — всё подготовлено под требования платформы ещё до первого экрана. Когда UI будет готов, запуск в модерацию MAX и включение ЮKassa — вопрос флага, а не отдельного квартала работы.
Нужен такой же подход?
Собираем с нуля сложные продукты: Mini App для MAX и Telegram, SaaS с подписками, админки, боты с вебхуками, интеграции с CRM и платёжными системами. Полный стек, собственная инфра, документация, с которой может работать любая команда. Оценим сроки и бюджет бесплатно.