ProFreelance — глобальний маркетплейс фрилансу на спільному ядрі

01Огляд проєкту

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

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

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

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

02Контекст і задача

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

За цим запитом стояв зрозумілий набір болів і обмежень, з якими ми працювали:

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

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

03Цілі проєкту

Із задачі виросли конкретні продуктові й інженерні цілі, які ми тримали у фокусі на всіх етапах:

• Запустити другий бренд на спільному ядрі. Максимально перевикористати доменну модель і сервіси платформи, мінімізуючи дублювання коду між проєктами екосистеми.
• Знизити поріг входу. Дати можливість зареєструватися й почати користуватися майданчиком за пару кліків — через вхід за соціальними мережами, без довгих форм і обов'язкового підтвердження пошти на старті.
• Прискорити розрахунки. Підключити поповнення балансу через крипто-шлюз Payora, щоб глобальна аудиторія могла швидко й передбачувано заводити кошти на майданчик.
• Розширити формати роботи. Увести окрему сутність «Завдання» — короткі задачі поряд із повноцінними проєктами, зі своїм життєвим циклом і спрощеним оформленням.
• Оновити інтерфейс. Зробити сучасну тему та редизайн, що відрізняють ProFreelance від базової платформи й створюють відчуття самостійного продукту.
• Зберегти безпеку угод і довіру. Не розгубити під час редизайну та спрощення те, заради чого маркетплейс існує: безпечні угоди, рейтинги, відгуки й передбачувані статуси.
• Закласти спільні сервіси між проєктами. Використати єдиний платіжний шар (Payora) і спільну інфраструктуру так, щоб кожен новий продукт екосистеми підключався до них без переписування.

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

04Що ми зробили

ProFreelance збирає цінність із чотирьох великих блоків, що разом і відрізняють його від базової платформи:

Поверх цих блоків — оновлена тема інтерфейсу, перемальовані ключові екрани (каталог, профіль, стрічка, картка проєкту та завдання), спрощений онбординг і зв'язка зі спільними сервісами екосистеми. Усе це розгорнуто як самостійний продукт на власному домені profreelance.biz за Cloudflare.

05Перевикористання платформи

Центральна інженерна ідея проєкту — не будувати другий маркетплейс з нуля, а перевикористати спільне ядро. ProFreelance і 24freelance належать одній родині рушія: у них спільна доменна модель і спільний набір налагоджених механік. Це означає, що найскладніше й найдорожче в маркетплейсі — логіка проєктів, відгуків, безпечних угод, рейтингів і статусів — уже написане, обкатане в бою й не потребує повторної розробки.

Що саме перевикористовується між проєктами екосистеми:

• Доменна модель. Користувачі та ролі (замовник/виконавець), проєкти, відгуки, угоди, рейтинги й відгуки, повідомлення — єдиний каркас, перевірений на робочому майданчику.
• Механіка безпечних угод. Логіка, за якою гроші й зобов'язання сторін захищені до завершення роботи, переноситься без переписування.
• Платіжний шар. Спільний крипто-шлюз Payora обслуговує кілька проєктів одразу: кожен підключається як окремий мерчант, але до того самого сервісу.
• Інфраструктурні патерни. Стек PHP, розміщення за Cloudflare, підходи до розгортання й експлуатації успадковані від базової платформи.

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

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

06Архітектура рішення

Архітектурно ProFreelance влаштований як окремий екземпляр платформи поверх спільного ядра, з власним брендом, доменом і набором надбудов. Базовий каркас успадковується від родини рушія, а унікальна для бренду функціональність зібрана в надбудовах, що не ламають спільну модель.

Логічно система ділиться на кілька шарів:

• Доменне ядро. Користувачі та ролі, проєкти, завдання, відгуки, угоди, рейтинги, повідомлення — спільна модель платформи, перевикористана з перевіреної бази.
• Шар бренду та UI. Оновлена тема, перемальовані екрани й тексти ProFreelance — те, що робить продукт самостійним візуально й за тоном.
• Онбординг. Вхід через соціальні мережі поверх спільної моделі користувачів: соцакаунт зіставляється із записом користувача майданчика.
• Платіжна інтеграція. Зв'язка із зовнішнім крипто-шлюзом Payora для поповнення балансу: створення рахунку, оплата на боці шлюзу й зарахування за підтвердженням.
• Сутність «Завдання». Окремий тип сутності поряд із проєктами, зі своїм спрощеним життєвим циклом, стрічкою й карткою.

Під капотом — серверний стек на PHP, розміщений за Cloudflare (DNS, TLS, захист периметра, кешування статики). Такий поділ на ядро й надбудови принциповий: він дозволяє розвивати бренд-шар ProFreelance незалежно, не зачіпаючи спільну доменну логіку, і навпаки — поліпшення у спільному ядрі можуть діставатися одразу кільком проєктам екосистеми.

07Вхід через соціальні мережі

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

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

З інженерного боку соцвхід акуратно ліг на спільну модель користувачів платформи:

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

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

08Поповнення балансу через Payora

Гроші на маркетплейсі мають заводитися швидко, передбачувано й без географічних бар'єрів. Для цього ProFreelance використовує крипто-шлюз Payora — той самий платіжний сервіс, що обслуговує й інші проєкти екосистеми. Це і є наочна цінність спільних сервісів: платіжний шар написаний і налагоджений один раз, а користуються ним одразу кілька продуктів.

Сценарій поповнення для користувача виглядає просто: він указує суму, майданчик створює рахунок у Payora, користувач оплачує його на боці шлюзу, а після підтвердження платежу баланс на ProFreelance поповнюється автоматично. Жодних ручних перевірок і очікувань «зв'яжіться з підтримкою».

Що це дає продукту:

• Швидкість. Крипто-розрахунки не впираються в банківські затримки й транскордонні обмеження — гроші доходять швидко.
• Передбачуваність. Життєвий цикл платежу зрозумілий: рахунок створено, оплачено, підтверджено, баланс нараховано. Менше спірних ситуацій.
• Глобальність. Для аудиторії по всьому світу крипто-поповнення часто зручніше й доступніше за локальні платіжні методи.
• Перевикористання. Майданчик не містить власного платіжного процесингу — він підключається до спільного шлюзу як мерчант, заощаджуючи розробку й знижуючи ризики.

09Сутність «Завдання»: короткі задачі

Не всяка робота — це великий проєкт із докладним ТЗ. Часто замовнику потрібна коротка разова задача: поправити верстку, перекласти сторінку, зібрати дані, зробити швидкий дизайн. Змушувати під таке оформлювати повноцінний проєкт — зайве тертя і для замовника, і для виконавця. Тому в ProFreelance з'явилася окрема сутність — «Завдання».

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

Що дає цей формат:

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

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

10Профілі, відгуки та безпечні угоди

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

Як це працює за ролями:

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

Сполучні механіки, що роблять майданчик робочим:

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

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

11Дизайн і редизайн інтерфейсу

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

Що торкнувся редизайн:

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

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

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

12Спільні сервіси екосистеми

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

Що розділяється між проєктами екосистеми:

• Платіжний шар. Крипто-шлюз Payora обслуговує поповнення балансу і в ProFreelance, і в інших проєктах. Кожен продукт підключається як окремий мерчант, але до того самого налагодженого сервісу.
• Доменне ядро. Спільна модель маркетплейсу (користувачі, проєкти, відгуки, угоди, рейтинги) перевикористовується між брендами, а не пишеться заново під кожен.
• Інфраструктурні підходи. Стек PHP, розміщення за Cloudflare, патерни розгортання й експлуатації успадковані й застосовуються однаково.

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

13Технологічний стек та інфраструктура

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

• Бекенд — PHP: доменне ядро маркетплейсу, логіка проєктів, завдань, відгуків, угод і рейтингів, перевикористана з перевіреної бази.
• Онбординг — вхід через соціальні мережі поверх спільної моделі користувачів, із зіставленням соцакаунта та запису майданчика.
• Платежі — інтеграція із зовнішнім крипто-шлюзом Payora для поповнення балансу; майданчик виступає мерчантом спільного сервісу.
• Надбудови бренду — оновлена тема, редизайн ключових екранів і сутність «Завдання» як окремий тип сутності.
• Інфраструктура — розміщення за Cloudflare (DNS, TLS, захист периметра, кешування статики) на власному домені profreelance.biz.

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

14Як ми працювали

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

• Дослідження й постановка. Розібрали, що перевикористовується зі спільного ядра, а що будується заново під бренд; зафіксували аудиторію, гео й відмінності від базової платформи.
• Шар бренду. Спроєктували оновлену тему та редизайн ключових екранів так, щоб продукт відчувався самостійним, не ламаючи перевірені сценарії.
• Онбординг. Упровадили вхід через соціальні мережі поверх спільної моделі користувачів і вибудували перші кроки навколо мінімуму тертя.
• Платежі. Підключили поповнення балансу через крипто-шлюз Payora як спільний сервіс екосистеми, із зарахуванням за підтвердженням платежу.
• Сутність «Завдання». Додали формат коротких задач поряд із проєктами — зі своїм життєвим циклом, стрічкою й карткою.
• Запуск. Розгорнули продукт на власному домені за Cloudflare й зібрали все у зв'язний, самостійний маркетплейс.

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

15Результат

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

• Другий маркетплейс запущено швидше й дешевше завдяки перевикористанню спільного ядра, а не повторній розробці.
• Поріг входу знижено соцвходом: реєстрація й перший крок — за пару кліків, без довгих форм.
• Розрахунки прискорено крипто-поповненням через Payora — спільний платіжний сервіс обслуговує кілька проєктів одразу.
• Формати роботи розширено сутністю «Завдання»: короткі задачі живуть поряд із проєктами й утримують дрібний оборот на майданчику.
• Безпечні угоди, рейтинги й відгуки збережено — фундамент довіри перенесено без ризиків.

16Висновки

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

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

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