Скільки коштує створити маркетплейс: від перевірки попиту до платформи

Чому маркетплейс дорожчий за інтернет-магазин

В інтернет-магазині один продавець — ви — і багато покупців. У маркетплейсі багато і тих, і тих, і кожній стороні потрібен власний продукт:

• Сторона покупця: пошук, оголошення, бронювання чи замовлення, оплата, відстеження замовлення, відгуки.
• Сторона пропозиції: реєстрація й перевірка, профілі й оголошення, графік чи залишки, обробка замовлень, виплати, рейтинги.
• Правила між ними: хто кому й коли платить, комісія, скасування й повернення коштів, спори, модерація, журнал, який ніхто не може переписати.
• Сторона оператора: команда в адмінці, яка схвалює продавців, модерує оголошення, розв’язує спори й стежить за цифрами.

Кожна з цих частин — набір модулів. Тому фразу «маркетплейс як Airbnb, тільки для X» неможливо оцінити без подробиць: за нею ховаються чотири продукти.

Сторону оператора легко пропустити в пропозиції, бо користувачі її не бачать. Але саме адмінка визначає, скільки людей знадобиться вам для щоденної роботи. Якщо схвалити продавця, повернути гроші чи розібрати скаргу можна лише через розробника, кожна така дія зрештою коштуватиме дорожче, ніж модуль, який би її взяв на себе.

Орієнтовні ціни у 2026 році

Орієнтир для пропозицій студій в Україні та Східній Європі, а не прайс; остаточну суму визначає обсяг робіт, а оцінка розкладе його на модулі з ціною:

На шкалі MVP зі статті скільки коштує розробка MVP MVP маркетплейсу стоїть на верхній межі діапазону продуктів із кількома ролями: у нього дві-три ролі, як у будь-якого такого продукту, плюс утримання оплати до виконання й виплати продавцям. Загальна логіка з тієї статті теж діє: менше ролей, менше інтеграцій і ручний бекофіс знижують суму.

Модулі, що рухають ціну

Оплата: модуль, який легко недооцінити

Взяти гроші в однієї людини й виплатити іншій — саме тут маркетплейс найбільше відрізняється від магазину. Платформа має:

• прийняти оплату покупця й утримувати її, доки замовлення не виконано чи не підтверджено;
• відрахувати комісію, а решту виплатити продавцю;
• обробляти скасування, часткові повернення й чарджбеки;
• знати, хто її продавці, бо про це запитають і платіжні сервіси, і закон.

Є й юридичні питання. Утримання чужих грошей у деяких країнах може вимагати ліцензії, тож надійніше спертися на спеціальний продукт платіжного сервісу для маркетплейсів: гроші утримує й переказує сервіс, а не платформа. Який сервіс підійде, залежить від ваших країн і бізнес-моделі; Stripe Connect — один із варіантів там, де працює Stripe, а в Україні набір варіантів інший. Поговоріть із платіжним сервісом і юристом до того, як проєктувати процес оплати, а не після.

Для MVP найдешевша чесна версія зазвичай така: оплата карткою, гроші утримує платіжний сервіс, а виплату запускає ваш адміністратор після виконання замовлення. Автоматичні виплати й детальні правила повернень можуть почекати, доки цього не вимагатиме обсяг угод.

Крок за кроком такий мінімальний процес виглядає так:

1. Покупець платить карткою; гроші утримує платіжний сервіс, замовлення отримує статус «оплачено».
2. Продавець приймає замовлення — або відхиляє, і покупець отримує повне повернення.
3. Роботу виконано; покупець підтверджує це, або замовлення підтверджується саме через визначену кількість днів без скарг.
4. Адміністратор запускає виплату: частка продавця йде йому, комісія лишається платформі.
5. Якщо покупець відкриває спір, виплату заморожують, доки адміністратор не вирішить: повне повернення, часткове чи виплата продавцю.

Кожен крок — це статус, сповіщення потрібній стороні й рядок у звіті для бухгалтерії. Тому оплата забирає помітну частку бюджету MVP маркетплейсу навіть у найпростішій чесній версії.

Суміжне питання — коли саме гроші стають доходом платформи. Якщо комісію утримують у момент виплати продавцю, бухгалтерії потрібно бачити кожну угоду окремо: оплату покупця, комісію, виплату й повернення, якщо воно було. Закладіть звіт для бухгалтерії в першу версію — це дешевше, ніж потім відновлювати ці цифри вручну.

Коли продукт — це довіра

Деякі маркетплейси продають не стільки оголошення, скільки довіру між незнайомими людьми. A-Search, маркетплейс перевірки авто з нашого портфоліо, — один із прикладів: покупець платить за незалежну перевірку машини, яку не може побачити сам. У таких продуктах основна вага бюджету не в сторінках оголошень, а в тому, що робить роботу незнайомої людини вартою довіри: сталий чекліст із доказами до кожного пункту, оплата, що утримується до отримання результату, зрозумілий шлях для спорів, журнал, який ніхто не може переписати, і один життєвий цикл замовлення, який кожна роль бачить зі свого боку. Якщо ваш продукт — це довіра між незнайомими людьми, ці модулі не опційні, а пропозиція без них — це пропозиція на інший продукт.

Один маркетплейс — дві перші версії

Візьмімо умовний маркетплейс прибирання квартир в одному місті.

Версія А, мінімальна. Вебзастосунок. Прибиральників підключає ваша команда після співбесіди. Клієнт обирає послугу й час і платить карткою; гроші утримуються, доки роботу не позначено виконаною, а виплату запускає адміністратор. Після виконаного замовлення клієнт ставить оцінку. Решту операцій ведуть з адмінки.

Версія Б, усе й одразу. Мобільні застосунки для обох сторін, самостійна реєстрація прибиральників із перевіркою документів, миттєві автоматичні виплати, платні тарифи для виконавців, чат у застосунку, процедура спорів з арбітражем і три міста на старті.

Версія А відповідає на єдине запитання, важливе на старті, — чи будуть люди бронювати, платити й повертатися, — за частку вартості версії Б. Кожен пункт із Б — розумне рішення на потім, ухвалене вже з даними з версії А. У таблиці вище версія А — це MVP маркетплейсу в нижній частині свого діапазону, а версія Б — платформа для зростання з першого дня, з відповідним бюджетом і п’ятьма-дев’ятьма місяцями роботи.

Найдешевший маркетплейс — вузький

Бюджет маркетплейсу легко спалити на ширині: усі категорії, усі міста, усі ролі одразу. Дешевший і зазвичай мудріший шлях:

• Одна ніша, одне місто чи один тип угод. Доведіть, що угоди відбуваються й повторюються.
• Спершу пропозиція. Підключайте продавців вручну, імпортуйте каталоги чи фіди партнерів, щоб покупці не потрапили в порожній маркетплейс. Докладніше — у статті як запустити маркетплейс.
• Операції ведуть люди. Підбір, модерація й виплати — з адмінки; автоматизуйте їх згодом.
• Спершу веб, потім мобільний застосунок. Для перших угод вистачить адаптивного вебзастосунку; мобільний окуповується, коли люди повертаються часто.
• Відгуки лише після реальних замовлень — з першого дня. Додати довіру згодом складніше, ніж закласти її одразу.

Що має увійти в першу версію, крок за кроком розібрано в статті MVP маркетплейсу: що потрібно в першій версії.

Запитання, що змінюють оцінку

Перш ніж просити ціну, запишіть відповіді на ці запитання. Кожне з них може посунути суму на цілий модуль:

• Гроші проходять через платформу чи покупці платять продавцям напряму?
• Хто встановлює ціну: продавець, платформа чи домовленість між сторонами?
• Це разова покупка, бронювання часу чи послуга з кількома етапами?
• Як ви перевіряєте продавця, перш ніж він почне продавати?
• Що буде, коли покупець скаже, що замовлення виконали не так, як обіцяли?
• Звідки прийдуть перші сто продавців?
• Яка сторона частіше сидить у телефоні, ніж за ноутбуком?

Відповіді не мусять бути остаточними. «Поки не знаємо» — теж відповідь, просто розробник закладе під неї ризик.

Поточні витрати, на які варто розраховувати

• Комісії за оплату з кожної угоди — для продуктів для маркетплейсів вони можуть бути вищими, ніж для звичайної оплати карткою; перевірте тариф сервісу.
• Перевірка особи й документів, якщо ви перевіряєте продавців через сервіс.
• Час на модерацію й підтримку — це люди, а не код, і їх потрібно більше з ростом обсягів.
• Хостинг, карти, SMS і пошта, а також сховище для фото й документів.
• Розробка наступної категорії, міста чи ролі, бо маркетплейс, що росте, постійно змінює форму.

Попросіть розробника розписати технічні витрати окремо, а витрати на людей порахуйте самі: їх не покаже жодна пропозиція.

Як ми оцінюємо маркетплейс

Опишіть маркетплейс своїми словами — текстом, посиланням, файлом чи голосовим повідомленням, — і оцінка приблизно за 15 секунд розкладе його на модулі — каталог, замовлення, оплати, кабінети, адмінку — з годинами, термінами й ціною. Оцінка безкоштовна й ні до чого не зобов’язує. На розборі з командою ми допомагаємо скоротити першу версію до того, що потрібно першим угодам, а потім договір фіксує ціну. Маркетплейс рухає чужі гроші, тому в EVA-X для першої версії радимо AI + DEV, а з ростом обсягів — DEV; AI Build підходить для клікабельного прототипу, на якому перевіряють попит із кількома користувачами. Що саме ми робимо — на сторінці розробка маркетплейсу під ключ.