Сколько стоит создать маркетплейс в 2026 году

Сколько стоит создать маркетплейс в 2026 году, зависит от модели сделки и способа запуска. В бюджете нужно разделить платформу, её настройку, разработку недостающих функций и эксплуатацию. Готовую лицензию можно оценить по тарифу поставщика; заказную разработку — по составу работ. Сильнее всего на смету влияют расчёты с продавцами, доставка, интеграции и правила обработки заказов.

В этой статье речь о собственной площадке, где разные продавцы предлагают товары или услуги. Бюджет выхода на чужой маркетплейс считают иначе. Здесь владельцу предстоит организовать работу обеих сторон: покупатель должен получить заказ, продавец — увидеть его условия и свой доход, оператор — разобраться, если сделка пошла не по плану.

Какую площадку вы собираетесь запускать

Начните со сценария сделки. Каталог поставщиков с передачей заявки, магазин нескольких продавцов с общей корзиной и сервис аренды с календарём занятости могут выглядеть похоже. Но за экранами работают разные правила. Именно их придётся спроектировать, реализовать и проверить.

• Товарная площадка: варианты товара, остатки, корзина, разделение заказа по продавцам, доставка и возвраты
• Площадка услуг: выбор исполнителя, заявка или запись на время, подтверждение выполнения, отмена и спор
• Аренда: доступность на нужные даты, срок пользования, продление, залог и возврат предмета аренды
• B2B-площадка: закупка от имени компании, права сотрудников, цены по условиям покупателя, согласование заказа
• Каталог с заявками: поиск предложения и передача контакта продавцу; завершение сделки может происходить за пределами площадки

Затем определите источник дохода: комиссия со сделки, подписка продавца, плата за заявку или продвижение предложения. Для комиссии потребуется учитывать завершённые и отменённые сделки. Для подписки — срок доступа и продление. Для платной заявки — правило, по которому продавец принимает её или оспаривает списание.

Например, наш маркетплейс записей IT-собеседований помогает кандидатам готовиться к интервью по реальным записям и зарабатывать на собственном опыте. Для такого продукта важен доступ к материалу. Правила отгрузки физического товара к этой задаче не относятся — переносить их в смету нет смысла.

Что дешевле: конструктор, коробка или своя разработка

Конструктор — сервис по подписке, в котором площадку собирают через настройки. Он подходит, когда предусмотренный поставщиком путь сделки совпадает с вашим. Проверьте доступные способы оплаты, работу с продавцами, выгрузку данных и ограничения тарифов. Возможность менять внешний вид ещё не означает, что можно изменить правила заказа.

Для ориентира: на момент проверки 9 октября 2026 года рабочий тариф Live у Sharetribe указан как $199 в месяц при годовой оплате. Использование сверх включённого объёма оплачивается отдельно; цены опубликованы без НДС. Это пример стоимости сервиса, без работ по подготовке конкретного бизнеса к запуску. Доступность подключения и подходящих платежей нужно проверять для своей страны и компании. Источник — официальные тарифы Sharetribe.

Коробка — готовая платформа, которую устанавливают и настраивают под проект. В ней уже могут быть каталог, кабинеты продавцов и управление заказами. Например, у русской версии Multi-Vendor годовая подписка «Стандарт» стоит 108 900 ₽, «Плюс» — 218 900 ₽; бессрочная лицензия «Плюс» — 544 490 ₽. Это цены поставщика на 9 октября 2026 года, без оценки внедрения вашего проекта. Состав редакций и условия обновлений различаются — их нужно сверить в таблице лицензий Multi-Vendor.

Своя разработка позволяет заложить нужные правила без привязки к устройству готовой платформы. Она оправданна, когда отличия затрагивают саму сделку: например, заказ требует согласований или цена зависит от сочетания условий. Но готовые функции тоже придётся создавать и поддерживать. Сравнивайте стоимость запуска и дальнейших изменений: коробка может хорошо подходить бизнесу годами, а большой объём переделок способен лишить её ценового преимущества.

Из чего складывается стоимость создания маркетплейса

В смете должны быть видны результаты работы. Строка «личный кабинет» почти ничего не объясняет: в одном случае продавец только меняет описание, в другом управляет сотрудниками, складами и возвратами. Попросите раскрыть действия каждой роли и условия, при которых эти действия доступны.

• Проектирование: схема сделки, роли, прототипы экранов, границы первой версии и критерии приёмки
• Каталог: категории и характеристики, поиск, фильтры, импорт, проверка карточек; отдельно — объединение предложений разных продавцов в одну карточку товара
• Кабинеты: действия покупателя, продавца и оператора, права сотрудников, доступ к заказам и данным
• Заказы: статусы, резервирование, отмены, частичное выполнение, уведомления и история изменений
• Расчёты: приём оплаты, комиссия площадки, распределение денег, возвраты и сверка операций
• Запуск: настройка серверов, перенос начальных данных, тестирование, резервное копирование и обучение оператора

Роль не обязательно требует отдельного приложения или кабинета: сотрудникам можно дать разные права внутри одного интерфейса. Однако каждое ограничение нужно проверить. Продавец не должен увидеть чужие заказы, а менеджер каталога — случайно изменить настройки выплат. Подробность этих правил влияет на стоимость разработки маркетплейса сильнее, чем число пунктов в меню.

Почему оплата и сплит платежей требуют отдельной оценки

До разработки оплаты нарисуйте путь денег: кто принимает платёж, какую сумму получает продавец, как удерживается комиссия и что происходит при отмене. Отдельно согласуйте с платёжным партнёром правила подключения продавцов, а с бухгалтером и юристом — подходящую схему расчётов и чеков. Эти решения задают требования к системе.

Сплитование позволяет распределить один платёж между несколькими получателями. Например, в ЮKassa площадка передаёт данные о распределении суммы между магазинами и своей комиссии. Это описано в документации по сплитованию платежей. Само разделение суммы не означает, что деньги будут удерживаться до доставки: условия подтверждения и перечисления надо согласовать отдельно.

Представим покупку у нескольких продавцов: один подтвердил наличие, другой отменил свою часть. Система должна сохранить выполненную часть заказа, вернуть нужную сумму и правильно пересчитать комиссию. Затем эти операции должны совпасть в кабинете покупателя, отчёте продавца и данных платёжного сервиса. Такую проверку нельзя заменить успешной оплатой тестовой корзины.

Оценивать платёжный модуль нужно вместе с отменами, возвратами и сверкой операций

Как логистика и интеграции увеличивают смету

Если продавцы отправляют товары со своих складов, одна корзина может превратиться в несколько посылок с разными сроками и ценой доставки. Нужно решить, когда покупатель увидит итоговую сумму, можно ли выбрать разные пункты выдачи и куда отправлять возврат. Собственный склад площадки добавляет приёмку, размещение и сборку заказов.

Фраза «интеграция с 1С» тоже не определяет объём работ. Важно, чья это система, какие данные передаются, в какую сторону и как часто. Один обмен с учётной системой оператора отличается от подключения учётных систем независимых продавцов. У них могут различаться справочники, настройки и качество данных.

• Для каждой интеграции перечислите данные: товары, цены, остатки, заказы, статусы доставки
• Назначьте источник верных данных: где исправляют цену или остаток, если системы расходятся
• Определите поведение при сбое: повторная отправка, уведомление оператору, временная остановка продажи
• Уточните, кто предоставляет доступ и тестовые данные, кто оплачивает сторонний сервис
• Включите проверку дублей: повторное уведомление не должно создавать второй заказ или повторную операцию

В нашем приложении для закупки электроники предусмотрены административная панель, передача товарных данных из МойСклад и сопоставление позиций из прайс-листов поставщиков. Этот пример показывает, почему подготовку ассортимента стоит обсуждать отдельно от витрины. Наличие исходных товаров ещё не означает, что они готовы к поиску и сравнению.

Как сократить первую версию и сохранить рабочую сделку

Сначала выберите один путь: покупатель находит предложение, оформляет заказ, получает результат; продавец видит заказ и расчёт, оператор может разрешить проблему. Для проверки спроса не всегда нужны мобильное приложение, программа лояльности и собственный чат. Но отказ от них должен соответствовать привычкам вашей аудитории.

Часть операций допустимо оставить сотрудникам: проверку карточек, подключение продавцов, разбор спорных заказов. Для каждой такой операции назначьте ответственного и способ учёта. Иначе экономия на разработке превратится в потерянные заявки и часы поиска причины ошибки. В разработке MVP для стартапов границы первой версии стоит связывать с конкретной гипотезой: что именно вы хотите узнать по первым сделкам.

Отдельно проверьте готовую платформу на неудобных сценариях: продавец изменил цену после оформления, товар закончился, покупатель запросил частичный возврат. Если для каждого случая требуется переделка, низкая цена лицензии мало говорит об итоговом бюджете. Если сценарии уже предусмотрены, писать их заново может быть незачем.

Сколько времени займёт запуск

Срок конкретного маркетплейса нельзя вывести из цены лицензии или числа экранов. Сначала нужно проверить сложные зависимости: подключение платежей, доступность обмена с учётными системами, качество товарных данных. Без этого календарь отражает только работу разработчиков и пропускает ожидание внешних участников.

• До оценки: описать модель площадки, участников сделки, монетизацию и ограничения запуска
• На проектировании: согласовать сценарии, прототип и критерии готовности; проверить спорные интеграции
• На разработке: показывать законченные сценарии и фиксировать изменения состава работ
• Перед запуском: загрузить ассортимент, обучить оператора, проверить оплату, отмены и восстановление после сбоя
• На пилоте: провести сделки с ограниченным кругом участников и устранить обнаруженные проблемы

Просите отдельные даты для демонстрации сценария, начала пилота и публичного запуска. Между ними есть работа заказчика: подготовка ассортимента, участие продавцов, согласование правил. В Quantum Dev кликабельный прототип показываем за день до старта проекта; он помогает обсудить интерфейс, но ещё не выполняет платежи и обмен данными. Сроки этапов фиксируем после определения состава работ.

Что платить после запуска

Соберите бюджет владения за выбранный период: разработка и внедрение, лицензии, инфраструктура, работа команды площадки, поддержка и привлечение участников. Не задавайте всем расходам одинаковый процент от разработки. Серверы зависят от нагрузки и хранения данных, поддержка — от режима обслуживания, расходы платёжного сервиса — от его тарифа и операций.

• Регулярные технические расходы: серверы, хранение файлов, резервные копии, мониторинг, продление лицензий
• Расходы по использованию: приём платежей, выплаты, сообщения, внешние сервисы и их платные лимиты
• Работа площадки: модерация, помощь покупателям, подключение продавцов, подготовка карточек
• Развитие продукта: новые сценарии, изменения интеграций, обновления и проверка совместимости
• Привлечение обеих сторон: поиск продавцов и покупателей с отдельным учётом затрат и результата

Считайте доход площадки отдельно от оборота продавцов. Из комиссии по завершённой сделке вычитайте связанные с ней расходы: платёжные операции, поддержку, скидки за счёт площадки и субсидирование доставки. Затем сопоставляйте остаток с постоянными расходами. Так станет видно, при каких условиях рост числа заказов помогает бизнесу, а при каких увеличивает убыток.

Как сравнить предложения подрядчиков

Слова «разработка маркетплейса под ключ» в коммерческом предложении сами по себе ничего не гарантируют. В одном предложении окажется установка платформы, в другом — проектирование, интеграции и помощь с запуском. Сравнивать итоговые суммы можно после проверки состава работ и исключений.

• Одинаково ли описана первая версия: роли, сценарии заказа, способы оплаты, отмены и возвраты
• Включены ли дизайн, адаптация для телефона, загрузка данных, тестирование и запуск
• Какие лицензии и сервисы оплачиваются отдельно; указаны ли условия налогов и продления
• Что заказчик должен предоставить и как задержка этих материалов влияет на календарь
• Как оплачиваются изменения, чем подтверждается готовность этапа и что входит в исправление ошибок
• Кому принадлежат результаты разработки, где хранятся исходники и какие доступы получает заказчик

Основа сопоставимой оценки — описание функций и проверок для приёмки. Если его пока нет, начните с разработки технического задания. В Quantum Dev состав работ фиксируем в ТЗ, этапы, сроки и стоимость — в дополнительных соглашениях. Исключительные права на результат после оплаты переходят заказчику. Стоимость маркетплейса называем после бесплатной оценки: общей суммы для всех моделей площадок у нас нет.

Подготовьте описание сделки, список ролей и систем, которые нужно связать с площадкой. Добавьте макеты, экраны или ссылки, если они есть, и отметьте функции, без которых нельзя провести первый заказ. На разработке маркетплейса в Quantum Dev поможем определить состав запуска и оценить работы — стоимость назовём после бесплатной оценки.