Як створити маркетплейс: практичний посібник з MVP

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

Що насправді є маркетплейсом

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

Дані

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

Права доступу

Маркетплейси найчастіше ламаються саме на правах доступу. Запишіть правила:

• Будь-хто може переглядати опубліковані оголошення.
• Лише продавець, якому належить оголошення, може його редагувати або видаляти.
• Покупці бачать лише власні запити й повідомлення; продавці — лише запити щодо своїх оголошень.
• Адміністратори можуть бачити й модерувати все.
• Контактні дані відкриваються лише тоді, коли ви вирішите — наприклад, після підтвердження бронювання.

Перевіряйте це, увійшовши як один користувач і спробувавши відкрити сторінки іншого.

Рішення та компроміси

Почніть вузько

«Маркетплейс для всього» не має ані пропозиції, ані аудиторії. «Оренда фотоапаратури на вихідні в Лісабоні» можна заповнити вручну. Вузькі категорії роблять і MVP меншим: менше полів, менше фільтрів, менше граничних випадків.

Кого залучати першим

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

Як рухаються гроші

Це найважливіше рішення, і є три поширені відповіді:

1. Без платежів на платформі. Покупці пишуть продавцям і платять їм напряму. Ви заробляєте на платі за оголошення, виділених розміщеннях або підписці для продавців. Найпростіше в побудові; найслабкіший контроль над угодою.
2. Ви берете плату лише з продавця. Продавці платять вам підписку або плату за оголошення через звичайний checkout. Все ще просто — так само, як будь-який платний застосунок.
3. Покупці платять через платформу, а ви виплачуєте продавцям. Ви берете комісію з кожної угоди. Саме це найчастіше уявляють люди, і саме тут складність.

Платежі та виплати: чесна версія

Прийняти платіж карткою — добре відома річ. Розділити цей платіж і більшу його частину надіслати третій стороні — інша задача. Зазвичай потрібен платіжний продукт, створений для платформ, як-от Stripe Connect, а не звичайний checkout.

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

На практиці це означає роботу понад кнопку оплати:

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

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

Перший промпт для конструктора на ШІ

Опишіть дві сторони, оголошення, угоду та права доступу — і залиште платежі поза першою версією:

Створи MVP маркетплейсу під назвою GearShare, де фотографи в Лісабоні здають одне одному в оренду фототехніку. Продавці реєструються, створюють оголошення (назва, категорія, опис, денна ціна, до 6 фото, район) і бачать запити щодо своїх оголошень. Покупці переглядають за категорією, шукають за ключовим словом, фільтрують за ціною та районом, відкривають оголошення і надсилають запит на оренду з датами та повідомленням. Кожен користувач бачить лише власні запити й повідомлення. Додай сторінку адміністратора, щоб схвалювати нові оголошення перед публікацією та приховувати оголошення. Зберігай усе в базі даних, а фото — у файловому сховищі. Поки без платежів — на підтверджених запитах показуй «Домовтеся про оплату з власником». Мобільний дизайн, чистий стиль.

Потім будуйте частинами: спершу оголошення, потім пошук і фільтри, потім запити та повідомлення, потім адмін-панель. Тестуйте кожну частину, перш ніж рухатися далі.

Кроки побудови

1. Оберіть нішу і напишіть два шляхи користувачів, по кілька речень кожен.
2. Визначте поля оголошення та категорії. Тримайте це стисло.
3. Побудуйте оголошення та перегляд з реалістичними тестовими даними.
4. Додайте облікові записи та ролі і протестуйте кожне правило доступу.
5. Додайте угоду — запит, запит на бронювання або повідомлення.
6. Додайте адміністрування та модерацію: схвалення, приховування, блокування, редагування.
7. Додайте email-сповіщення, щоб люди знали про новий запит.
8. Запустіть з вручну залученою пропозицією у вашій ніші й стежте за реальними угодами.
9. Лише потім додавайте платежі, починаючи з тестового режиму та невеликої групи перевірених продавців.
10. Додайте відгуки, коли буде достатньо завершених угод для оцінювання.

Типові помилки

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

Витрати та інструменти

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

Коли краще готовий продукт

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

Створення з Mythex

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

Корисна документація: створення CRUD-застосунку, додавання входу (власна автентифікація) і прийом платежів через Stripe. Шаблон маркетплейсу оренди дає стартовий промпт, а наш посібник з MVP SaaS пояснює, як тримати першу версію малою.

Запитання