Розробка B2B2C-платформи

Уявіть: ви запускаєте маркетплейс, де сотні партнерів продають послуги кінцевим клієнтам. Дані різних партнерів не повинні перетинатися — інакше витік або порушення NDA. Як організувати ізоляцію без втрати продуктивності? Це завдання, яке ми вирішуємо щодня протягом 8 років. За цей час ми реалізували 45+ проєктів для маркетплейсів та агрегаторів.

B2B2C-платформа об'єднує оператора, бізнес-партнерів і кінцевих споживачів. Кожен рівень має свої інтерфейси та правила доступу. Розробка B2B2C-платформи під ключ з ізоляцією даних — наша спеціалізація. Ми використовуємо сучасний стек: React, Node.js, PostgreSQL. У цій статті розберемо ключові аспекти: як налаштувати multi-tenancy, white-label та розрахунки.

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

Трирівнева архітектура

Платформа (оператор)
    ↓ надає інфраструктуру
Бізнес-партнери (B2B-клієнти, вендори, постачальники послуг)
    ↓ обслуговують через платформу
Кінцеві споживачі (B2C-користувачі)

Кожен рівень має свій інтерфейс і правила доступу:

• Оператор — суперадмін, бачить все, керує партнерами
• Партнер — бачить лише своїх клієнтів і свою аналітику
• Споживач — бачить лише свій контент і послуги

Чому важлива ізоляція даних?

Дані різних партнерів не повинні змішуватися — це питання безпеки та довіри. Ми використовуємо три стратегії isolation:

• Row-Level Security (RLS) — єдина база з tenant-фільтром, дешево та масштабовано до тисяч партнерів.
• Окремі схеми PostgreSQL — краща ізоляція, але складніші міграції.
• Окремі бази даних — максимальна ізоляція для enterprise-партнерів.

Порівняння стратегій:

Multi-tenancy з RLS у 3 рази простіше в адмініструванні, ніж окремі бази даних.

CREATE POLICY tenant_policy ON orders
USING (tenant_id = current_setting('app.tenant_id')::int);

Згідно з PostgreSQL Documentation, RLS дозволяє ефективно ізолювати дані на рівні рядків.

Як налаштувати white-label?

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

• Кастомний домен (partner.yourdomain.com)
• Логотип та кольорова схема на основі CSS-змінних
• Кастомні email-шаблони сповіщень

Middleware визначає тенант за доменом, завантажує налаштування з бази та застосовує тему. White-label рішення в 2 рази швидше за iframe-вбудовування.

Що таке B2B2C multi-tenancy?

Архітектурний патерн multi-tenancy передбачає, що одна інстанція застосунку обслуговує безліч клієнтів (тенантів). У B2B2C-платформі кожен партнер є тенантом. Розробка B2B2C платформи з ізоляцією даних вимагає вибору стратегії multi-tenancy залежно від кількості партнерів та вимог до безпеки.

Розрахунок взаєморозрахунків

У B2B2C-платформі три сторони беруть участь у транзакції:

• Споживач платить X
• Партнер отримує X − комісія платформи
• Платформа отримує комісію

Додатково враховуються реферальні програми, партнерські знижки та промокоди. Типова економія на комісіях при автоматизації розрахунків — до 30%. Автоматизація економить до 300 000 грн на рік для середнього партнера. Середня вартість ліцензії на одного партнера — від 10 000 грн на місяць.

Аналітика за рівнями

• Оператор бачить загальний обіг, активність партнерів, когортний аналіз, відтік
• Партнер бачить лише своїх споживачів, їхню активність, доходи, конверсії
• Споживач бачить свої замовлення, історію, рекомендації

Аналітика партнера ізольована — порівняльні метрики з іншими партнерами не показуються за замовчуванням.

Онбординг партнерів

Чим простіше зареєструватися та запустити роботу, тим вища конверсія в активних партнерів. Типовий процес:

1. Реєстрація компанії з документами
2. Wizard налаштування (бренд, перший продукт)
3. Тестовий режим (sandbox-платежі, перевірка інтеграцій)
4. Публікація в продакшн

Термін від реєстрації до першої транзакції — не більше 1–2 днів. Понад 90% партнерів успішно проходять онбординг.

Що входить до роботи

При замовленні розробки B2B2C-платформи ми надаємо:

• Архітектурна документація (ERD, sequence diagrams)
• CI/CD з ізоляцією середовищ
• Інтеграція з платіжними системами (Stripe, ЮKassa)
• Навчання команди партнера
• Техпідтримка на 3 місяці (вартість — від 50 000 грн на місяць)

Технічний стек

Терміни

MVP B2B2C-платформи з управлінням партнерами, white-label, ізоляцією даних та базовими фінансами: 4–6 місяців. Бюджет на розробку MVP зазвичай становить від 2 до 4 млн грн. Повноцінна платформа з маркетплейсом, мобільними застосунками та аналітикою: 8–14 місяців.

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

Розробка корпоративних порталів та внутрішніх систем

Ми займаємося розробкою корпоративних порталів — CRM, ERP, LMS та Intranet. Кожен такий проект починається не з верстки лендінгу, а з того, як бізнес-правила ляжуть в архітектуру: хто бачить які дані, як синхронізуються 1С та облікова система, як 500 контактів перетворюються на 500 000 без падіння продуктивності. За 7 років ми реалізували понад 40 порталів для компаній з чисельністю від 50 до 5000 співробітників. Оцінимо ваш проект за два робочі дні — просто зв'яжіться з нами.

Як ми забезпечуємо якість архітектури?

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

Три зони, де найчастіше приймаються погані рішення, — модель прав доступу, продуктивність на великих даних та real-time оновлення.

Як побудувати рольову модель для 30 відділів?

Модель прав доступу. «Менеджер бачить тільки своїх клієнтів, керівник відділу — весь відділ, директор — всю компанію, але фінансові дані — тільки фінансовий директор і вище». Це не три ролі — це матриця з ролей, дозволів, організаційних одиниць та володіння записами. Якщо це реалізувати через if ($user->role === 'manager') в контролерах — через півроку код стане непідтримуваним.

Правильний підхід: Spatie Laravel Permission для базової рольової моделі + Policy класи для object-level permission (can('view', $deal) перевіряє не тільки роль, але й володіння). Для складних ієрархічних структур — ABAC (Attribute-Based Access Control) замість RBAC.

Продуктивність на великих даних. CRM з 500 000 контактів, фільтрація по 10 полях, сортування за активністю — це задача, де наївна реалізація видає 15-секундні запити. Composite indexes, денормалізація агрегатів (last_activity_at на самому записі замість MAX по зв'язаній таблиці), Elasticsearch для full-text пошуку по контактах.

Real-time оновлення. Декілька співробітників працюють з одним документом або задачею. Без WebSocket — постійні setInterval з polling кожні 5 секунд, зайве навантаження на сервер, затримка оновлень. Laravel Broadcasting + Pusher/Soketi або власний WebSocket сервер на Node.js — для сповіщень та змін у реальному часі.

CRM-системи

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

Pipeline з кастомними стадіями. Кожна компанія хоче свою воронку. Стадії повинні бути налаштовуваними без деплою. Таблиця pipeline_stages з position, color, is_final, probability — і drag-and-drop для зміни порядку на UI (React DnD або dnd-kit).

Історія змін. Хто і коли змінив статус угоди, поміняв відповідального, додав нотатку. Audit log через Observer або spatie/laravel-activitylog. На UI — timeline з фільтрацією за типом активності.

Інтеграція з поштою. IMAP/SMTP для підключення корпоративної скриньки, автоматична прив'язка вхідних листів до контактів за email-адресою. Це надійно працює тільки при правильній обробці bounce, spam, авто-відповідей — потрібна фільтрація.

Чому ERP — не про код, а про дані?

ERP — це коли CRM, склад, виробництво, бухгалтерія та HR об'єднані в єдину систему. Повний ERP з нуля — рідкісна задача (зазвичай інтегруються з існуючими системами), але модульні системи під конкретний бізнес — регулярна.

Ключовий принцип: фінансові операції повинні бути незмінними. Не UPDATE orders SET status = 'cancelled' — а створення нового запису order_cancellations з посиланням на вихідне замовлення. Це принцип immutable ledger, який спрощує аудит та reconciliation.

Інтеграція з 1С — майже завжди частина ERP-проекту. Двостороння синхронізація: з 1С в портал (довідники, залишки, ціни) та з порталу в 1С (замовлення, документи). RabbitMQ як шина подій між системами надійніше прямого HTTP-взаємодії — у випадку недоступності 1С повідомлення чекають в черзі.

Як влаштовані LMS: платформи навчання

Learning Management System — це курси, модулі, уроки, тести, сертифікати, прогрес користувачів.

Відео-контент — найбільш навантажена частина LMS. Зберігати відео на власному сервері та віддавати через Nginx — погана ідея: дорого, повільно, немає адаптивного бітрейту. Правильно: завантаження в S3/Cloudflare R2, транскодування через AWS Elemental MediaConvert або Mux, HLS-плейлист для адаптивного стрімінгу через Video.js або Plyr.

Прогрес перегляду — через періодичне відправлення watch_position з фронтенду (кожні 10–30 секунд), зберігання в Redis з періодичною синхронізацією в PostgreSQL. Не зберігати кожну секунду в БД — це вб'є продуктивність.

SCORM-сумісність — якщо потрібна інтеграція з корпоративними тренінговими матеріалами. Окремий модуль, є готові бібліотеки (scorm-again).

Intranet та HR-портали

Корпоративний інтранет: новини, документи, оргструктура, HR-процеси (відпустки, заявки, KPI).

Оргструктура в базі даних — це ієрархічна структура. Adjacency list (parent_id на кожному записі) простий в реалізації, але повільний при рекурсивних запитах. Nested Sets або Closure Table швидше для читання ієрархії, складніше при змінах. В PostgreSQL — рекурсивні CTE (WITH RECURSIVE) з adjacency list — баланс між простотою та продуктивністю.

Погодження документів та заявок — workflow engine. Прості лінійні погодження (співробітник → менеджер → HR → бухгалтер) можна зробити без спеціального движка. Нелінійні (паралельні гілки, умовні переходи, делегування) — варто розглянути готові рішення: Temporal.io для workflow orchestration або власний скінченний автомат на базі патерну state-machine.

Що входить в роботу

При замовленні розробки корпоративного порталу ви отримуєте:

• Архітектурну документацію (ER-діаграми, схема інтеграцій, матриця ролей)
• Повний код в Git-репозиторії з CI/CD
• Доступи до інфраструктури (хостинг, бази даних, сховища)
• Навчання адміністраторів та ключових користувачів (2–3 сесії)
• Гарантійну підтримку на 3 місяці після запуску

Наші принципи проєктування спираються на офіційну документацію Laravel з авторизації (Policies) та рекомендації щодо роботи з чергами.

Технічний стек для порталів

Орієнтири за термінами

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