MVP маркетплейсу: що потрібно в першій версії, а що може почекати

Правило: будуйте під перші угоди

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

У типовому маркетплейсі цей цикл має шість кроків:

1. Продавець чи виконавець розміщує пропозицію.
2. Покупець її знаходить.
3. Вони домовляються, і покупець платить.
4. Продавець виконує замовлення.
5. Платформа виплачує гроші й залишає собі комісію.
6. Обидві сторони залишають слід: відгук, запис, спір, якщо щось пішло не так.

Якщо функція не робить жоден із цих кроків можливим чи безпечнішим, вона не для першого дня.

Функції першого дня для кожної сторони

Для покупців

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

Для продавців чи виконавців

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

Для вашої команди адміністраторів

Цю сторону найлегше пропустити, а саме вона тримає молодий маркетплейс на плаву.

• Модерація профілів і пропозицій до публікації.
• Інструменти ручного залучення: створити продавця, завантажити його пропозиції, перевірити документи.
• Усі замовлення в одному вікні зі статусом та історією.
• Можливість втрутитися: скасувати, повернути гроші, передати іншому виконавцю, скоригувати.
• Черга спорів із чіткими правилами.
• Налаштування комісії та базові звіти про замовлення й гроші.
• Журнал усіх чутливих дій.

Гроші

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

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

Довіра

Довіру проєктують, а не додають згодом. У перший день це означає:

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

Що може почекати і що робити тим часом

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

Коли ручну роботу варто перетворити на функцію

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

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

Ведіть простий журнал: що команда адміністраторів щотижня робить вручну і скільки часу на це йде. За місяць-два наступна версія майже напише себе сама.

Скільки ручної роботи закладати

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

Проблема курки та яйця — це питання обсягу робіт

Маркетплейс без продавців не має покупців, і навпаки. Вихід — у тому, що ви будуєте першим:

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

Отже, інструменти для пропозиції мають бути в першій версії. Імпорт із таблиці чи фіду партнера, масове створення пропозицій і адміністратор, який може діяти від імені продавця, — саме це не дає маркетплейсу відкритися порожнім. Детальніше — у статті про те, як запустити маркетплейс.

Приклад: довіра як продукт

Візьмімо маркетплейс перевірки вживаних авто перед купівлею — таку платформу ми зробили як A-SEARCH (сторінка кейсу зараз в архіві). Покупець бачить авто в оголошенні далеко від себе, але не бачить його реального стану; незалежний місцевий інспектор перевіряє машину на місці й надсилає звіт.

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

Цей урок підходить і іншим маркетплейсам послуг: з’ясуйте, що робить першу угоду безпечною для обох сторін, і збудуйте це раніше за все інше.

Помилки, через які MVP стає завеликим або крихким

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

Що вимірювати з першого дня

Команда аналітиків не потрібна, але кілька показників потрібні з першого тижня:

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

Ці показники підкажуть, яку функцію будувати наступною, — а саме для цього MVP і потрібен.

Бюджет і терміни: орієнтир

Функції вище лягають на три умовні стадії. Ціни студій в Україні та Східній Європі у 2026 році приблизно вкладаються в такі діапазони:

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

Який формат розробки підходить

Маркетплейс рухає чужі гроші. Для першої версії ми радимо AI + DEV, де оплати, виплати й спори ведуть інженери, а з ростом обсягів — DEV. AI Build підійде для клікабельного прототипу, щоб перевірити попит на кількох користувачах, ще до того, як рухатимуться справжні гроші.

В EVA-X ми розбиваємо маркетплейс на модулі, тож перша версія несе лише те, що потрібно першим угодам, за ціною, зафіксованою в договорі. Подивіться нашу послугу розробки маркетплейсу або опишіть свій маркетплейс в оцінці, щоб побачити модулі й ціну.