Запрос «нужен маркетплейс под ключ» почти всегда звучит проще, чем сам проект. Снаружи видны каталог, корзина и кабинет. Через 5 рабочих дней предпроектного анализа (discovery) обычно выясняется, что рядом уже стоят комиссии, выплаты, возвраты, модерация, споры, документы и интеграции, а общий объем вырос на 40-70%.
Я к этому отношусь спокойно, потому что картина повторяется из проекта в проект. Мы сами когда-то слишком буквально поняли фразу «сделайте кабинет продавца», а потом потеряли 5 недель на перепроектирование выплат в уже работающей системе. После таких историй маркетплейс воспринимается не как набор экранов, а как операционная машина, где ошибка в правилах обычно дороже ошибки в интерфейсе.
Тут почти всегда не один продукт, а три
Самая частая ошибка в смете - посчитать витрину и не учесть все, что держит ее в рабочем состоянии. У живого маркетплейса почти всегда есть buyer app, seller cabinet и admin panel. В B2B нередко добавляется еще операторская зона для менеджеров и бухгалтерии.
В прошлом году у нас был проект в дистрибуции, где клиент рассчитывал уложиться в 2,5 млн ₽. Уже на первой неделе в список вошли модерация карточек, журнал выплат, споры по заказам, акты, уведомления в Telegram и интеграция с amoCRM. Оценка сдвинулась к 4,1 млн ₽, и это еще был аккуратный MVP без мобильного приложения.
Мини-диалог в таких проектах обычно повторяется почти дословно:
- Нам нужен простой маркетплейс.
- Продавцы сами загружают товары?
- Да, конечно.
- Кто проверяет карточки, считает комиссию и ведет выплаты?
- Это тоже нужно.
Фраза «это тоже нужно» в маркетплейсе почти всегда означает новую бизнес-ветку, а не еще один экран.
Сначала надо считать роли и деньги, а не экраны в Figma
Красивые макеты дают ложное ощущение, что проект уже понятен. На практике я сначала прошу карту ролей и схему движения денег: кто платит платформе, когда заказ считается завершенным, кто инициирует возврат, в какой момент продавцу доступны деньги, как удерживаются штрафы и комиссия.
Обычно discovery с проектированием занимает 2-6 недель и стоит заметно дешевле переделки после релиза. Если платформа берет комиссию, но не умеет вести раздельный учет по продавцам, это потом бьет по бухгалтерии, поддержке и доверию продавцов. Такие узлы мы стараемся закрывать до первого экрана.
Для первого релиза список почти всегда довольно приземленный:
- витрина и поиск
- кабинет продавца
- админка с модерацией
- платежи, уведомления, базовая отчетность
Первые 3-6 месяцев обычно разумнее тратить на проверку спроса и процессов. Полный набор пожеланий на этом этапе редко помогает запуску.
Личный кабинет обычно и есть половина работы
Запрос «сделайте личный кабинет» звучит невинно, пока не начинаешь раскладывать роли. У покупателя один набор действий, у продавца другой, у администратора третий. Попытка собрать все в общий «профиль» почти всегда оборачивается дорогим компромиссом.
На проекте в нише оборудования для салонов seller cabinet занял 38% всего MVP. Внутри были загрузка товаров, остатки по складам, цены по регионам, возвраты, баланс, документы и уведомления. Снаружи это выглядело как несколько экранов, а по сути было отдельным B2B-инструментом.
Однажды мы попробовали пойти через единый кабинет и развести доступы флагами. Это была ошибка, и выяснилось это довольно быстро: через 7 недель стало понятно, что модель прав запуталась, менеджеры начали править руками, а QA увяз в нестандартных сценариях.
До и после нормального разделения ролей разница обычно выглядит так:
| Было | Стало |
|---|---|
| общий профиль | buyer / seller / admin |
| ручные правки заказов | понятные статусы |
| хаос в доступах | ролевая модель |
| долгий QA | быстрее на 25-30% |
if (user.role === 'seller' && order.sellerId === user.id) {
allow('read_order')
}
Для первой версии почти всегда выгоднее спокойная архитектура
Я не вижу смысла тащить микросервисы в проект, где еще не проверены экономика и процесс продаж. Для большинства запусков в 2026 году нам хватает модульного монолита: фронтенд на Next.js 15 или React 19, бэкенд на Laravel 11 либо Node.js 20 + NestJS, дальше PostgreSQL 16, Redis, OpenSearch и Docker.
Такой стек дает нормальную скорость запуска и не раздувает DevOps-слой раньше времени. По нашим оценкам, первая версия на модульном монолите выходит на 20-30% быстрее и дешевле в поддержке маленькой командой. Когда бизнес действительно упирается в нагрузку, архитектуру можно разносить осмысленно, а не следуя моде.
Мы однажды зашли в сложную схему слишком рано и просто подарили инфраструктуре 700 тыс. ₽ на старте. На продажах это не сказалось, зато релизный цикл стал длиннее.
Цена без границ MVP почти ничего не значит
Когда меня спрашивают, сколько стоит маркетплейс, я обычно отвечаю тремя вопросами: сколько ролей в системе, как устроены денежные потоки и что войдет в первый релиз. Без этого любая цифра остается декоративной. «Каталог с регистрацией продавцов» и платформа с выплатами, актами, спорами и логистикой - это разные классы продукта.
По срокам картина обычно такая: discovery 2-6 недель, MVP 3-6 месяцев, рабочая версия для роста 6-12+ месяцев. Чаще всего в оценке недосчитывают seller cabinet, финансовый модуль и интеграции. На демо они редко производят впечатление, но именно там живет значительная часть backend-логики.
Если вам называют цену за маркетплейс без карты ролей и правил движения денег, вы пока обсуждаете не разработку, а картинку. На практике бизнес потом живет в правилах, которые никто еще даже не посчитал. По данным рынка, именно этот разрыв между витриной и операционным контуром и остается одной из главных причин, почему бюджет на запуск у маркетплейсов пересматривают уже после старта.
