White-Labeling Your SaaS: Architecture, Branding, and Multi-Tenancy

White-labeling transforms your SaaS product into a platform that customers can rebrand and resell as their own. Instead of selling to 1,000 individual users, you sell to 10 agencies who each resell to 100 users. It's a powerful growth lever — but only if your architecture can handle it without collapsing under the weight of custom branding, isolated data, and unique configurations.

At Propelius Technologies, we've built white-label platforms for marketing agencies, HR software providers, and ecommerce tools. This guide covers the technical decisions that make white-labeling work at scale.

What Is White-Labeling?

White-labeling means your product can be rebranded to look like it was built by someone else. Your customer (a reseller/partner/agency) gets to:

• Use their own logo, colors, and typography
• Host it on their custom domain (partner.com instead of yourapp.com/partner)
• Remove all references to your brand
• Sometimes add/remove features per agreement
• Bill their customers directly

Common white-label use cases:

• Marketing agencies: Rebrand your SEO/analytics tool for their clients
• HR platforms: Consulting firms brand applicant tracking as their own
• Ecommerce tools: Web dev shops offer "their" store builder
• Booking systems: Service providers brand appointment scheduling

Multi-Tenant Architecture Models for White-Label

Your white-label platform needs to isolate each partner's data and branding. There are three main approaches:

1. Shared Database, Shared Schema

How it works: All partners share the same tables. Every record has a tenant_id column. Your queries filter by tenant.

Pros:

• Simplest to implement and maintain
• Lowest infrastructure cost
• Easy to add new tenants
• Database migrations apply to everyone

Cons:

• Risk of data leakage if you forget WHERE tenant_id = ?
• One bad query can slow everyone down
• Hard to customize database schema per tenant
• Backup/restore affects all tenants

Best for: Early-stage products with standard feature set across all partners.

2. Shared Database, Separate Schemas

How it works: One database with a schema per tenant (PostgreSQL schemas, MySQL databases). Each tenant's data lives in their own namespace.

Pros:

• Better data isolation than shared schema
• Per-tenant customization possible
• Easier to back up/restore individual tenants
• SQL query filters not needed (switch schema)

Cons:

• More complex migrations (run against N schemas)
• Connection pooling harder to optimize
• Database limits on schema count (varies by provider)
• Cross-tenant reporting requires federation

Best for: Mid-market SaaS with some per-tenant customization needs.

3. Separate Databases

How it works: Each tenant gets their own database instance (sometimes entire cluster).

Pros:

• Maximum isolation and security
• Per-tenant performance optimization
• Easy to move tenants between hosts
• Full customization possible
• Simplifies compliance (data residency)

Cons:

• Highest infrastructure cost
• Complex deployment and migration processes
• Monitoring N databases instead of 1
• Backups and scaling per tenant

Best for: Enterprise white-label platforms with strict security or data residency requirements.

Model	Cost	Isolation	Complexity	Customization
Shared Schema	$	Low	Low	Limited
Separate Schemas	$$	Medium	Medium	Moderate
Separate Databases	$$$	High	High	Full

Dynamic Branding System

Each partner needs to customize appearance without touching code. Here's what to support:

Visual Identity

• Logo: Header logo, favicon, email logo (different sizes/ratios)
• Colors: Primary, secondary, accent, success/error states
• Typography: Font family (self-hosted or Google Fonts), sizes, weights
• CSS variables: Inject tenant CSS as :root variables

Implementation:

:root {
  --primary-color: {{tenant.primaryColor}};
  --logo-url: url('{{tenant.logoUrl}}');
  --font-family: {{tenant.fontFamily}};
}

Text Content

• Product name: "Acme Analytics" instead of "Your Product"
• Taglines and CTAs: Customizable button text
• Support contact: Partner's email/phone/chat
• Legal pages: Terms, privacy policy URLs

Domain Routing

Partners want app.partnersite.com instead of yourapp.com/partner. Two approaches:

Option 1: CNAME + TLS certificate management

• Partner adds CNAME app.partnersite.com → proxy.yourplatform.com
• Your server detects Host header, looks up tenant, serves branded app
• Use Let's Encrypt DNS-01 challenge or wildcard cert per partner

Option 2: Reverse proxy with SNI routing

• Cloudflare for SaaS or AWS CloudFront custom domains
• Automatically provisions SSL certs
• Routes based on SNI hostname to your origin

Propelius recommendation: Use Cloudflare for SaaS. It handles certificate provisioning, global CDN, DDoS protection, and costs ~$2/domain/month.

Feature Toggles and Pricing Tiers

Different partners pay different amounts and get different features. Implement this with feature flags:

{
  "tenant_id": "acme",
  "plan": "enterprise",
  "features": {
    "advanced_analytics": true,
    "api_access": true,
    "white_label": true,
    "sso": true
  }
}

Check features in your backend:

if tenant.has_feature('advanced_analytics'):
    return advanced_report()
else:
    return basic_report()

Use feature flag services like LaunchDarkly, Flagsmith, or build your own with Redis.

Authentication and Authorization

Tenant-Aware Authentication

Users belong to a tenant. Your auth flow must identify both:

Option 1: Email-based tenant detection

• User enters email → lookup which tenant(s) they belong to → redirect to branded login
• Works for shared schema models

Option 2: Domain-based tenant detection

• User visits app.acme.com → server detects tenant from domain → shows Acme branding
• Cleaner UX, requires custom domains

SSO Support

Enterprise partners expect SAML or OAuth SSO. Implement per-tenant SSO configuration:

• SAML: Store IdP metadata per tenant
• OAuth: Store client ID/secret per tenant for Google Workspace, Microsoft Entra
• JIT provisioning: Auto-create users on first SSO login

Use libraries like ruby-saml, python-saml, or SaaS solutions like Auth0, WorkOS.

Billing Models for White-Label SaaS

1. Flat Fee Per Partner

Charge partners a fixed monthly/annual fee. They handle billing to their end users.

Pros: Simple, predictable revenue
Cons: Doesn't scale with partner's growth

2. Revenue Share

Partner pays you a percentage of what they charge their customers.

Pros: Aligns incentives, scales with partner success
Cons: Requires auditing partner revenue (trust issues)

3. Usage-Based (Per Seat/Transaction)

Charge based on end-user count, API calls, storage, etc.

Pros: Fair pricing, scales automatically
Cons: Complex metering and billing

4. Hybrid (Base + Overage)

Base fee + usage charges above threshold.

Example: $500/month + $5/seat above 100 users

Data Migration and Portability

Partners will want to:

• Import existing data: CSV uploads, API migration scripts
• Export their data: Full backups in JSON/CSV format
• Move to self-hosted: Provide database dumps (PostgreSQL .sql, MongoDB JSON)

Plan for churn: make offboarding painless to build trust during sales.

Performance and Scaling Considerations

• Tenant sharding: Distribute large tenants to dedicated infrastructure
• Cache per tenant: Redis keys namespaced by tenant_id
• Background jobs: Queue per tenant to prevent one slow job blocking others
• Rate limiting: Per-tenant API rate limits
• Monitoring: Metrics tagged by tenant_id to identify outliers

FAQs

Should I build white-label support from day one?

No. Build for direct customers first, validate product-market fit, then add white-labeling when you have inbound demand from resellers. Retrofitting is hard but doable — building it too early is premature optimization.

How do I prevent data leakage between tenants?

Use middleware that automatically injects tenant_id filters into all queries. Never trust client-provided tenant IDs. Use database-level row security policies (PostgreSQL RLS) as a second layer. Regular penetration testing and code reviews are essential.

Can partners customize the database schema?

Not in shared schema models. With separate schemas or databases, you can allow custom fields via JSON columns (PostgreSQL JSONB) or EAV (Entity-Attribute-Value) tables. True schema customization requires separate databases and versioned migration systems.

What about GDPR and data residency requirements?

Separate databases per tenant make this easier — store EU customers in EU regions, US customers in US regions. With shared databases, you'll need geo-sharding (complex). Many white-label customers need data residency guarantees, so plan for multi-region deployment early.

How do I handle different timezones across partners?

Store all dates in UTC. Let each tenant configure their timezone. Display dates in tenant timezone on frontend. For scheduled jobs (reports, emails), trigger based on tenant's local time by calculating offset from UTC.

Conclusion

White-labeling is a powerful distribution strategy that turns your SaaS into a platform. It requires careful architectural decisions around multi-tenancy, branding, authentication, and billing.

Start simple: Shared schema with tenant_id filtering. Add custom domains and branding. Launch with 3-5 pilot partners.

Scale strategically: Move large tenants to separate schemas or databases as needed. Invest in tenant-aware monitoring and performance optimization.

Build for portability: Make data export and migration easy. Partners who trust they can leave are more likely to stay.

At Propelius Technologies, we've built white-label platforms from scratch and retrofitted existing SaaS products for multi-tenancy. Get in touch to discuss your white-label architecture.