B2B2C Platform Development with Data Isolation
Imagine you launch a marketplace where hundreds of partners sell services to end customers. Data from different partners must not intersect — or risk leaks and NDA violations. How do you organize isolation without losing performance? This is a challenge we solve every day. Over the years, we have delivered 45+ projects for marketplaces and aggregators.
A B2B2C platform combines an operator, business partners, and end consumers. Each level has its own interfaces and access rules. Turnkey development includes three-tier architecture, data isolation, and complex financial logic. We use a modern stack: React, Node.js, PostgreSQL. This article covers key aspects: setting up multi-tenancy, white-label, and calculations.
The platform must be flexible to adapt to different partners and reliable to run without failures. We choose a stack that ensures both. Let's start with architecture.
Three-Tier Architecture
Platform (operator) ↓ provides infrastructure Business partners (B2B clients, vendors, service providers) ↓ serve via the platform End consumers (B2C users) Each level has its own interface and access rules:
- Operator — superadmin, sees everything, manages partners
- Partner — sees only their clients and analytics
- Consumer — sees only their content and services
Problems We Solve
Data isolation
Data from different partners must not mix — this is a matter of security and trust. We use three isolation strategies:
-
Row-Level Security(RLS) — single database with tenant filter, cheap and scalable to thousands of partners. - Separate PostgreSQL schemas — better isolation, but migration complexity rises.
- Separate databases — maximum isolation for enterprise partners.
Comparison:
| Criterion | RLS | Schema per tenant | Separate DB |
|---|---|---|---|
| Isolation | Medium | High | Maximum |
| Migration complexity | Low | Medium | High |
| Performance at 1000 tenants | Excellent | Good | Satisfactory |
Example RLS policy
CREATE POLICY tenant_policy ON orders USING (tenant_id = current_setting('app.tenant_id')::int); According to PostgreSQL Documentation, RLS allows efficient row-level data isolation.
White-label complexity
Partners want the platform to look like their own product. White-label is implemented via:
- Custom domain (
partner.yourplatform.com) - Logo and color scheme based on CSS variables
- Custom email notification templates
Middleware determines the tenant by domain, loads settings from the database, and applies the theme. This approach works 2–3 times faster than iframe embedding.
Multi-tenant billing
In a B2B2C platform, three parties participate in a transaction:
- Consumer pays X
- Partner receives X − platform commission
- Platform receives commission
Additional factors: referral programs, partner discounts, and promo codes. Automated reconciliation reduces commission leakage by up to 30% in typical setups.
How We Do It: A Case Study
For an aggregator of logistics services, we built a full white-label platform with 200+ tenants. We used PostgreSQL RLS combined with schema-per-tier for critical financial data. Each partner got a branded subdomain and custom checkout flow. The billing engine handles tiered commissions and real-time payouts. Onboarding time from registration to first transaction averaged 1.5 days. The platform processes over 10,000 transactions daily with 99.9% uptime under standard SLAs.
Our Process
- Data gathering — analyze partner tiers, data sensitivity, compliance requirements.
- Audit/analysis — review existing infrastructure, discuss integration points.
- Design — propose multi-tenancy strategy, white-label architecture, billing logic.
- Estimation — provide timeline and cost breakdown based on scope.
- Development — build with CI/CD, isolated environments for each tenant.
- Testing — load testing with realistic tenant mix, security audit.
- Launch — phased rollout, monitoring, and knowledge transfer.
Timelines
- MVP with partner management, white-label, data isolation, and basic finances: 4–6 months.
- Full platform with marketplace, mobile apps, and analytics: 8–14 months.
Exact duration depends on feature set, number of integrations, and partner volume. We adjust sprint planning after the initial audit.
Common Mistakes & Pitfalls
- Starting with separate databases for every tenant — increases cost and migration effort unnecessarily; start with RLS and scale up when needed.
- Not planning for tenant-aware caching — global caches can leak data between tenants; use per-tenant cache keys or separate cache instances.
- Ignoring regional compliance — if partners operate in different jurisdictions (GDPR, CCPA), the platform must support data residency at the tenant level.
What's Included in Our Work
When you order B2B2C platform development, we provide:
- Architectural documentation (ERD, sequence diagrams)
- CI/CD with environment isolation
- Integration with payment systems (Stripe Connect, YooKassa)
- Partner team training
- Technical support for the first 3 months
Full scope is defined during estimation.
Technical Stack
| Component | Technology |
|---|---|
| Tenant isolation | PostgreSQL RLS + schema per tenant |
| White-label | Subdomains + CSS custom properties |
| Auth | OAuth2 (separate clients for partner and consumer) |
| Payments | Stripe Connect / Yookassa agency scheme |
| Analytics | ClickHouse or PostgreSQL + Metabase |
Get Started
Contact us to discuss your project. Our engineers hold AWS and PostgreSQL certifications and can help choose the optimal architecture for your needs.