Маркетплейс — не просто інтернет-магазин з кількома продавцями. Це три паралельні додатки: покупець, продавець, адміністратор. Ми розробляємо такі системи під ключ: від прототипу до публікації в сторах. Архітектурні рішення на старті визначають, наскільки легко додавати нового продавця або новий тип товару через пів року. Замовте консультацію з архітектури вашого маркетплейсу — оцінимо проєкт за 2 дні.
Як спроектувати мобільний додаток маркетплейсу з нуля?
Маркетплейс поєднує два клієнти: покупецький і продавчий. Завдання — зробити їх максимально перевикористовуваними. Для покупця критичні каталог, кошик з мультивендорними товарами та платіжний механізм. Для продавця — керування товарами, замовленнями та аналітика. Збірка на React Native зі спільним core-пакетом скорочує час розробки на 30% порівняно з окремими нативними проєктами. Розглянемо кожну підсистему.
Як спроектувати каталог з мультивендорними фільтрами? — розробка мобільного додатку
Стандартний UICollectionView/RecyclerView з paginated endpoint працює, поки не з'явиться 50 продавців з пересічними категоріями. Проблема: при offset-пагінації виникають дублі, якщо продавець додав товар між запитами. Рішення — cursor-based пагінація (after=<last_item_id>): стабільніша при частому оновленні. Порівняння:
| Тип пагінації | Стабільність | Дублі при оновленні | Рекомендація |
|---|---|---|---|
| Offset | Низька | До 15% | Не використовувати для часто оновлюваних каталогів |
| Cursor-based | Висока | 0% | Стандарт для маркетплейсів |
WebSocket-канал у 10 разів швидший за polling за швидкістю оновлення даних. Stripe documentation рекомендує саме такий підхід для real-time сценаріїв.
Що робити з кошиком від різних продавців?
Користувач додав товари від трьох продавців — при checkout треба або розбити на три окремі замовлення, або створити один складовий з sub-orders. Це бізнес-рішення впливає на UI: розбивка за продавцями в кошику, окремі статуси доставки, можливість часткової оплати. Архітектуру кошика CartService з підтримкою VendorGroup узгоджуємо на старті. Кроки реалізації:
- Розділити кошик на секції за продавцями.
- При checkout запитати спосіб розбивки (окремі замовлення або складовий).
- На бекенді створити OrderGroup з дочірніми замовленнями.
- Обробляти платежі для кожного замовлення незалежно.
Як організувати real-time оновлення залишків?
Покупець дивиться товар, який у цей момент купили. Стандартна ситуація: товар у кошику, при checkout — out_of_stock. Хороше рішення — WebSocket-канал на детальній сторінці (wss://api/items/{id}/stock), що оновлює лічильник у реальному часі. Дешевий варіант — polling кожні 30 секунд через Timer. WebSocket кращий для частих змін (до 80% випадків), polling — для рідкісних.
Додаток продавця
Окремий target/модуль або окремий додаток — залежить від функціональності. Якщо продавець тільки керує товарами та переглядає замовлення — можна один target з role-based routing. Якщо потрібна аналітика, керування складом, чат — окремий додаток.
Обов'язкові функції продавця:
- Додавання та редагування товарів з фотографіями (завантаження в S3/Cloudinary через pre-signed URL з пристрою, без проксіювання)
- Вхідні замовлення з push-сповіщеннями (FCM/APNs з високим пріоритетом)
- Зміна статусу замовлення: прийнято → в обробці → відправлено → доставлено
- Звіт по продажах за період
Як організувати платежі в маркетплейсі?
Найскладніше — split-payment: покупець платить одну суму, гроші розщеплюються між продавцями та платформою. Stripe Connect, PayPal Marketplace або самописний шлюз. Stripe Connect: покупець платить через PaymentIntent з transfer_data, гроші розподіляються по Connected Account кожного продавця. На мобільному — стандартний Stripe SDK (stripe-ios, stripe-android) для UI карткової форми. Порівняння рішень:
| Рішення | Готовність | Комісія | Split-payment | Складність інтеграції |
|---|---|---|---|---|
| Stripe Connect | Висока | 2.9% + $0.30 | Вбудований | Середня |
| PayPal Marketplace | Висока | від 2.2% | Через Parallel Payments | Вища |
| Самописний шлюз | Низька | Немає комісії | Потребує розробки | Висока |
Split-payment інтеграція з Stripe Connect знижує операційні витрати на 40% порівняно з самописним рішенням. Якщо split-payment не потрібен (платформа збирає все, потім переказує продавцям) — простіше: звичайний платіжний шлюз, розрахунки через окрему систему виплат.
Пошук
Повнотекстовий пошук по каталогу з автодоповненням — не SQL LIKE. Elasticsearch або Meilisearch на бекенді, мобільний клієнт робить дебаунсований запит (300–500ms) при вводі. UISearchController (iOS) / SearchView (Android) з результатами в UITableView/RecyclerView. Попередні запити — в UserDefaults/SharedPreferences, показуємо при пустому полі.
Архітектура та стек
Для маркетплейсу з двома додатками React Native зі спільним core-пакетом — розумний вибір: перевикористання бізнес-логіки (CartService, OrderService, AuthService), окремі UI-шари для кожної ролі. Нативні Swift + Kotlin — коли потрібна специфічна продуктивність або hardware-інтеграції (NFC, сканер штрих-коду).
Архітектурний паттерн: Clean Architecture з UseCases/Interactors — дозволяє тестувати бізнес-логіку незалежно від UI-фреймворку. На React Native: Zustand або Redux Toolkit для стейту кошика та каталогу.
Чек-лист перевірки перед публікацією
- [ ] Каталог коректно відображає товари з різними продавцями
- [ ] Кошик правильно групує товари за продавцями
- [ ] Checkout створює коректні замовлення (окремі або складові)
- [ ] Платежі проходять з правильним розщепленням
- [ ] Push-сповіщення приходять на нові замовлення
- [ ] Залишки оновлюються в реальному часі
- [ ] Аналітика продавця відображає коректні дані
Що входить у роботу
- Технічне завдання та прототип архітектури
- UI/UX-дизайн для обох додатків (покупець, продавець)
- Розробка core-модулів (каталог, кошик, замовлення, платежі)
- Інтеграція платіжної системи (Stripe, PayPal)
- Налаштування push-сповіщень (FCM/APNs)
- Навантажувальне тестування каталогу та checkout
- Публікація в App Store та Google Play
- Документація та передача доступів
- Технічна підтримка 1 місяць після релізу
Процес
Discovery та проектування (ролі, флоу замовлення, платіжна схема) → UI/UX для обох додатків → розробка core-модулів → продавчий модуль → адміністративна панель → навантажувальне тестування → публікація.
Чому обирають нас
Ми — команда з 7+ роками досвіду в мобільній розробці, реалізували понад 15 маркетплейсів для iOS та Android. Гарантуємо дотримання App Store Review Guidelines та Google Play політик. Досвід роботи з split-payment, real-time сповіщеннями та високонавантаженими каталогами. Зв'яжіться з нами — отримайте безкоштовну консультацію з архітектури вашого маркетплейсу.
Орієнтири за строками
MVP маркетплейсу (каталог, кошик, checkout, базовий додаток продавця): 6–10 тижнів. Повнофункціональна платформа з split-payment, real-time сповіщеннями, пошуком та аналітикою: 3–5 місяців. Вартість розраховується індивідуально після аналізу вимог.