Розробка фріланс-біржі
Типова біль: замовник знаходить фрілансера під своє завдання, але не впевнений, що гроші не пропадуть. Фрілансер, своєю чергою, боїться працювати без передоплати. Фріланс-біржа вирішує обидві проблеми — escrow-система гарантує безпеку угод, а рейтинг і відгуки допомагають обрати перевіреного виконавця. Але побудувати таку платформу з нуля — інженерний виклик: потрібні не лише профілі та чат, а й складна платіжна інфраструктура, алгоритми ранжування, захист від шахраїв та масштабування під навантаження. Наприклад, під час завантаження списку фрілансерів легко отримати N+1 query, а неоптимізований SSR викликає hydration mismatch. Ми вирішуємо ці проблеми за допомогою бандл-спліттингу та Server Components.
Основні труднощі: як зробити так, щоб замовник і фрілансер не обходили платформу, як обробляти спори, як забезпечити швидкий пошук за навичками. Ми вирішуємо їх за допомогою NLP-фільтрів, автоматичної ескалації та Elasticsearch. Наша команда з 8+ років досвіду розробила понад 30 платформ для стартапів та середнього бізнесу. Ми будуємо фріланс-біржі під ключ — від прототипу до деплою.
Моделі роботи біржі
Job-based (як Upwork): замовник публікує завдання — фрілансери подають заявки з ціною та описом — замовник обирає — робота, оплата.
Gig-based (як Fiverr): фрілансер створює гіг із фіксованою ціною — замовник купує — виконавець виконує.
Комбінована: обидві моделі, користувач обирає прийнятну.
| Характеристика |
Job-based |
Gig-based |
| Ініціатива |
Замовник |
Фрілансер |
| Ціна |
Договірна / відгуки |
Фіксована |
| Глибина проєктів |
Складні, високий бюджет |
Прості, низький бюджет |
| Попит |
Унікальні навички |
Масові послуги |
Наприклад, job-based модель забезпечує до 40% вище утримання замовників за рахунок довгострокових проєктів, тоді як gig-based швидше масштабується.
Як працює ескроу?
Ескроу — ключова функція довіри. Схема:
1. Замовник приймає пропозицію
2. Замовник поповнює escrow (гроші утримуються платформою)
3. Фрілансер бачить, що гроші заблоковані → починає роботу
4. Фрілансер здає роботу → статус "submitted"
5. Замовник приймає → гроші переходять фрілансеру (мінус комісія)
АБО Замовник запитує правки → фрілансер доопрацьовує
АБО Відкривається спір (dispute)
Wikipedia визначає escrow як "договірну угоду, за якою третя сторона отримує та виплачує гроші або майно для основних сторін угоди".
Реалізація: Stripe PaymentIntent з capture_method: manual. Capture відбувається при прийнятті роботи. Це гарантує безпеку обох сторін: замовник не втрачає гроші, фрілансер впевнений в оплаті.
Чому важлива система рейтингу?
Рейтинг — основний фільтр якості. Ми реалізуємо розрахунок Job Success Score (відсоток успішних проєктів) та середню оцінку за відгуками. Алгоритм ранжування фрілансерів:
score = (avg_rating × W1) + (job_success_rate × W2) + (completed_jobs_log × W3)
+ profile_completeness × W4 - response_time_hours × W5
Фільтри: навички, бюджет, рівень, часовий пояс, мова, рейтинг, доступність. Така система відсіює недобросовісних виконавців та підвищує довіру.
Як працює milestone-оплата?
Для великих проєктів — оплата по етапах:
Project: розробка сайту (частина бюджету)
├── Milestone 1: дизайн → здача → оплата
├── Milestone 2: верстка → здача → оплата
└── Milestone 3: backend → здача → оплата
Кожен milestone — окремий escrow-платіж. Це безпечно для складних проєктів: замовник платить поетапно, а фрілансер отримує гроші за виконану частину.
Система спорів
При конфлікті (замовник не приймає / фрілансер не здає):
- Відкривається спір
- Обидві сторони надають докази (листування, файли)
- Медіатор (співробітник платформи) вивчає та виносить рішення
- Кошти звільняються згідно з рішенням (повністю / частково одній стороні)
Автоматичне закриття без спору: якщо замовник не прийняв/відхилив протягом N днів після здачі → автоматичне прийняття.
Комунікації
Вбудований чат з прив'язкою до контракту — все листування за проєктом в одному місці. Листування поза платформою послаблює позицію при спорі. Відеодзвінки: інтеграція з Daily.co або Zoom через API прямо з чату.
Захист від обходу платформи
Поширена проблема: замовник і фрілансер домовляються в обхід без комісії. Заходи:
- NLP-фільтрація чату: блокування контактних даних у перших повідомленнях
- Мінімальний час перед розкриттям контактів (після першого договору)
- Явна політика: обхід = блокування акаунту
Ці заходи знижують втрату комісії на 70%.
Основні етапи розробки
| Етап |
Тривалість |
Результат |
| Аналітика та прототипування |
2-4 тижні |
ТЗ, wireframes |
| Дизайн-система |
3-6 тижнів |
Figma макети |
| Розробка MVP |
3-4 місяці |
Працюючий продукт |
| Інтеграція платежів та ескроу |
2-3 тижні |
Stripe escrow |
| Тестування та деплой |
1-2 тижні |
CI/CD, навантажувальне тестування |
Що входить в роботу
Ми надаємо повний пакет:
- Технічне завдання та прототипування
- Дизайн-система (Figma)
- Розробка фронтенду та бекенду
- Інтеграція платіжного шлюзу (Stripe)
- Розгортання на сервері (Docker, CI/CD)
- Документація API та адмін-панелі
- Навчання команди замовника
- Підтримка 3 місяці після запуску
Терміни
MVP (завдання, пропозиції, вибір виконавця, escrow-платежі, відгуки): 4–5 місяців. Повноцінна біржа з gig-marketplace, milestone, спорами, відеодзвінками, мобільним додатком: 7–12 місяців.
Зв'яжіться з нами для попередньої оцінки вашого проєкту. Отримайте консультацію експерта з термінів та вартості розробки фріланс-біржі. Замовте технічний аудит поточної платформи — ми запропонуємо план оптимізації.
Ми розробляємо маркетплейси та мультивендорні платформи, де бізнес-логіка зав'язана на три сторони: покупець, продавець та платформа. Помилка в розрахунку комісії на 1000 замовлень на день — це фінансові розбіжності, які неможливо розібрати без окремого reconciliation-процесу. Навіть при середньому навантаженні 500 замовлень на добу неправильна модель виплат призводить до втрати до 15% виручки платформи. Ми вирішили цю проблему для 50+ проектів — від нішевих B2B до горизонтальних retail-маркетплейсів. Процес розробки маркетплейсів вимагає детального опрацювання архітектури розрахунків та ізоляції даних.
Як побудувати надійну мультивендорну платформу?
Як уникнути розбіжностей у розрахунках комісій
Розрахунок комісії — найкритичніша частина, де помилки коштують грошей. Правило перше: ніколи не зберігати комісію як похідну, завжди як факт. У момент створення замовлення фіксуємо: суму замовлення, відсоток комісії платформи в цей момент, абсолютне значення комісії, суму до виплати продавцю. Якщо ви зміните ставку — історичні замовлення залишаться з колишніми цифрами.
Моделі комісій (використовуємо одну з або комбінуємо):
| Модель |
Принцип |
Типовий сценарій |
| Фіксований відсоток |
5% з кожного продажу |
Прості торгові майданчики |
| Диференційований за категоріями |
Електроніка 3%, одяг 8% |
Маркетплейси з різними маржами |
| Tiered за оборотом |
До 100k — 10%, від 100k — 7% |
B2B-платформи з об'ємними знижками |
| Змішаний |
% + фіксована сума за транзакцію |
Високоризикові або дорогі товари |
Ми використовуємо Stripe Connect як базовий стандарт. Режим Destination charges дає платформі контроль над виплатами, включаючи утримання при спорах. Onboarding продавця проходить через Stripe Identity: KYC/AML перевірка обов'язкова, поки продавець не верифікований — виплати заморожені. Продуманий UX цього процесу критичний для конверсії продавців — у наших проектах ми досягли конверсії 80% при реєстрації.
Escrow та холдування — приклад реалізації
Гроші з покупця списуються одразу, продавцю переказуються із затримкою 7–14 днів після підтвердження отримання. Це захист від шахрайства та можливість утримання при спорах. Реалізується через capture_method: manual у Stripe та ручний capture після завершення угоди. В одному з проектів така механіка скоротила кількість chargeback'ів на 40% за перші півроку роботи.
Чому архітектура мультиарендності критична для ізоляції даних
Перший крок — вибір архітектури мультиарендності. У shared-schema режимі всі продавці в одних таблицях з vendor_id. Ми обов'язково впроваджуємо Row Level Security на рівні PostgreSQL та глобальні scopes в ORM (Laravel, Rails, Django). Це гарантує, що продавець не побачить чужих замовлень навіть при помилці розробника. Для enterprise-проектів з жорсткими вимогами GDPR використовуємо окремі схеми PostgreSQL — ізоляція строгіша, але cross-vendor аналітика складніша.
Як реалізувати складські залишки без race condition
Два покупці одночасно додають останній товар у кошик. Хто його купить? Застосовуємо optimistic locking при створенні замовлення:
UPDATE inventory
SET reserved = reserved + 1
WHERE product_id = ? AND (quantity - reserved) >= 1
Атомарна операція — другий запит поверне 0 зачеплених рядків та отримає помилку «товар закінчився». Типова схема для високонавантажених маркетплейсів.
Який підхід до каталогу товарів обрати: unified чи per-vendor?
Порівняння підходів до каталогу товарів:
| Аспект |
Unified-каталог (Amazon-like) |
Per-vendor-каталог (Avito-like) |
| Єдина картка товару |
Так, product → offers |
Ні, кожен продавець свою |
| SEO |
Оптимізується за карткою |
Дублікати, але швидший запуск |
| UX покупця |
Вищий (порівняння цін) |
Нижчий (багато дублів) |
| Складність розробки |
Висока (модерація атрибутів) |
Середня |
| Конверсія покупки |
На 25% вища |
Нижча |
Для нішевого B2B маркетплейсу ми частіше обираємо per-vendor — швидше запускається. Для горизонтального retail з сотнями продавців — unified-каталог дає кращий UX.
Пайплайн модерації: автоматика та ручна верифікація
Маркетплейс несе відповідальність за контент продавців. Типові проблеми: підроблені товари, заборонені категорії, маніпуляція цінами, фейкові відгуки. Вибудовуємо трирівневий пайплайн:
- Автоматичні перевірки при публікації: обов'язкові поля, відповідність категорії, стоп-лист слів, дублікати через хеш зображення.
- AI-класифікація (Amazon Rekognition або Vertex AI Vision) — детекція забороненого контенту та визначення категорії.
- Черга ручної перевірки для flagged товарів.
Статусна машина: draft → pending_review → active / rejected → suspended. Кожен перехід — подія з причиною та модератором. Продавець отримує сповіщення з конкретною причиною відмови, а не «порушення правил». Верифікація відгуків обов'язкова — тільки після підтвердженого замовлення. Автоматичний детектор флагує різке зростання відгуків від акаунтів з нульовою історією.
Пошук та рекомендації
Пошук по маркетплейсу з різними продавцями та сотнями тисяч товарів — це Elasticsearch або OpenSearch, не SQL LIKE. Векторний пошук для семантики, фасетна фільтрація через агрегації. Персоналізована стрічка на основі колаборативної фільтрації. A/B тестування алгоритмів ранжування обов'язкове — інтуїція тут поганий порадник.
Процес роботи
Маркетплейс — ітеративна розробка. MVP: реєстрація продавців, каталог товарів, кошик та checkout через Stripe Connect, базова модерація. Після запуску — дані про реальне використання визначають пріоритети наступних ітерацій.
Типовий порядок:
- MVP (3–4 місяці)
- Аналітика та зворотний зв'язок
- Перший розширений реліз (2–3 місяці)
- Масштабування та оптимізація
Терміни та вартість
- MVP маркетплейсу (каталог, checkout, базові профілі продавців): 3–5 місяців.
- Повнофункціональний маркетплейс з модерацією, розширеною аналітикою, мобільним додатком: 8–18 місяців.
- Додавання маркетплейс-функціональності до існуючого e-commerce: 2–5 місяців.
Вартість розробки розраховується індивідуально після аудиту вимог. Точну оцінку надамо на безкоштовному передпроектному обстеженні.
Що входить в роботу
- Проектна документація: архітектура, схеми даних, API-специфікації (OpenAPI).
- Доступи до репозиторію, CI/CD, документації з розгортання.
- Навчання команди замовника роботі з платформою.
- Технічна підтримка протягом першого місяця після запуску.
Ми гарантуємо коректність фінансових розрахунків та конфіденційність даних. Архітектурні принципи, на яких ми ґрунтуємося, підтверджені досвідом 10+ років та 50+ успішних проектів. Зв'яжіться з нами для попередньої оцінки вашого маркетплейсу — отримайте консультацію з архітектури та розрахунку виплат. Замовте аудит поточної платформи — виявимо вузькі місця та запропонуємо оптимізацію.
