White labeling is when you build a SaaS product that other businesses rebrand and sell as their own. Your platform does the heavy lifting. Your partners get a product with their logo, their domain, and their customer relationships. You get recurring revenue from every partner, multiplied by every customer they bring on.
It is one of the most powerful distribution models in software, and one of the most complex to build. We have architected white label platforms that serve dozens of partners, each with their own branding, features, and customer base, all running on a single codebase. The architecture decisions you make at the start determine whether this scales elegantly or collapses into a maintenance nightmare.
The Business Model
Before touching code, understand the economics. White label SaaS has a fundamentally different revenue model than traditional SaaS.
In traditional SaaS, you sell directly to end users. Your cost of acquisition is high (marketing, sales, support), but you keep 100% of the revenue. In white label SaaS, your partners handle acquisition. Your cost per end user is near zero, but you share revenue or charge a flat platform fee.
The common pricing models for white label platforms are:
- Per partner flat fee: Each partner pays a monthly fee for access to the platform. Simple to manage, but does not scale with their success.
- Per end user pricing: Partners pay based on how many customers they serve. Aligns incentives because you earn more as they grow.
- Revenue share: Partners pay a percentage of what they charge their customers. Highest alignment, but requires transparency into partner billing.
- Tiered platform fee plus per user: A base fee for the platform plus per seat pricing. This is the most common model because it provides baseline revenue with growth upside.
The right model depends on your market. If your partners are agencies reselling to small businesses, per end user pricing works well. If your partners are enterprises embedding your product into their offering, a revenue share or platform fee makes more sense. Understanding how SaaS products are built from the ground up helps clarify where white labeling fits into your broader strategy.
Multi Tenancy Architecture
White label SaaS is multi tenancy with an extra layer. You are not just isolating data between end users. You are isolating between partners, and each partner has their own set of end users.
This creates a three level hierarchy: your platform, your partners (tenants), and their customers (sub tenants). The architecture must cleanly separate all three levels.
There are three primary approaches to multi tenancy for white label platforms:
Shared database with row level isolation: All partners and their customers share a single database. Every table includes a `partner_id` column, and every query filters by it. This is the simplest to operate and the most cost effective. Row Level Security (RLS) in PostgreSQL enforces isolation at the database level. For most white label products with up to a few hundred partners, this is the right approach. Our multi tenant architecture guide covers this pattern in detail.
Schema per partner: Each partner gets their own database schema within a shared database. This provides stronger isolation than row level filtering and makes it easier to run partner specific migrations. The tradeoff is operational complexity, managing hundreds of schemas requires automation for migrations, backups, and monitoring.
Database per partner: Each partner gets their own database. This provides the strongest isolation and simplifies compliance (some enterprise partners require dedicated infrastructure). But it dramatically increases infrastructure cost and operational burden. Reserve this for partners who are paying enough to justify it.
Most successful white label platforms use a hybrid approach: shared database for standard partners, with the option to provision dedicated infrastructure for enterprise partners willing to pay a premium.
Branding and Customization Engine
The entire point of white labeling is that each partner's instance looks and feels like their own product. This requires a theming and customization system that goes beyond swapping a logo.
Build a configuration layer that supports:
- Visual branding: Logo, favicon, primary and secondary colors, font family, button styles, email header images
- Content customization: Product name, support email, terms of service URL, privacy policy URL, custom footer text
- Domain configuration: Each partner gets a custom domain (`app.partnerdomain.com`) or a subdomain (`partner.yourplatform.com`)
- Feature flags: Enable or disable specific features per partner based on their plan or agreement
- Email templates: Partner branded transactional and lifecycle emails
Store partner configuration in a JSON or JSONB column on the partners table. Load it at request time based on the incoming domain, and inject it into your application's theme context. The frontend should consume this configuration to render the correct branding without any code changes.
Custom domains are the hardest part. Each partner's domain needs SSL certificates, DNS configuration, and routing to the correct partner context. Use a wildcard certificate for subdomains of your platform domain, and provision individual certificates (via Let's Encrypt or a similar service) for fully custom domains. Your reverse proxy or CDN must route incoming requests to the correct partner context based on the domain.
Feature Flags and Partner Specific Behavior
Not every partner gets every feature. Some features are premium. Some are specific to certain industries. Some are experimental and only available to partners who opted in.
Implement a feature flag system scoped to partners:
- Global flags: Features that are on or off for the entire platform (new feature rollout, maintenance mode)
- Partner flags: Features enabled for specific partners (premium analytics, custom integrations, advanced reporting)
- Plan based flags: Features tied to the partner's pricing tier (basic, professional, enterprise)
The flag check in your code should be a simple function: `isFeatureEnabled('advanced_analytics', partnerId)`. This function checks the partner's plan, any partner specific overrides, and any global settings to return a boolean.
On the frontend, feature flags determine which navigation items, pages, and UI elements render. On the backend, they gate API endpoints and business logic. If a partner without the "API access" feature flag tries to generate an API key, return a 403 with a clear message about upgrading.
Data Architecture Considerations
White label data architecture has unique challenges that standard SaaS does not face:
Partner data ownership. Partners need to believe (and legally confirm) that their customer data belongs to them. Your data architecture must support data export and, ideally, data deletion when a partner leaves. Design for this from day one. Every piece of partner data should be traceable back to the partner and exportable in a standard format.
Analytics isolation. Each partner needs analytics about their customers, not about other partners' customers or the platform as a whole. Your analytics pipeline must respect the partner boundary. Pre aggregate metrics per partner and serve them from partner scoped dashboards.
Backups and recovery. If a partner accidentally deletes critical data, you need to restore it without affecting other partners. Time based backups of the entire database work, but point in time recovery for a single partner within a shared database requires more sophisticated tooling, like logical replication or partner scoped audit logs that can replay changes.
Partner Management Portal
Your partners need a portal to manage their white label instance. This is separate from the end user facing application and separate from your internal admin tools.
The partner portal should include:
- Branding configuration: Upload logos, set colors, configure custom domain
- User management: View and manage their end users
- Billing dashboard: See their usage, invoices, and plan details
- Analytics: Aggregate metrics about their customers' usage
- Support tools: Access to logs, ability to impersonate end users for debugging
- API management: If partners need programmatic access to manage their instance
Building the partner portal is a significant engineering investment, but it directly reduces your support burden. Every configuration a partner can make themselves is a support ticket you do not receive.
Deployment and Infrastructure
White label SaaS has specific infrastructure requirements that go beyond standard system architecture:
Request routing. Every incoming request must be mapped to a partner based on the domain. This happens at the reverse proxy or CDN level. Cache the domain to partner mapping aggressively because this lookup happens on every single request.
Asset serving. Partner specific assets (logos, favicons, custom CSS) need to be served from a CDN with the correct cache headers. When a partner updates their logo, the CDN cache must be invalidated.
Email sending. Each partner may need emails sent from their own domain. This means managing SPF, DKIM, and DMARC records for every partner domain, or using a shared sending domain with partner branding in the email content.
SSL certificate management. For custom domains, you need automated certificate provisioning and renewal. This is a solved problem with tools like Caddy or cert manager, but it requires operational attention.
When White Label Makes Sense
White label SaaS is not right for every product. It makes sense when:
- Your product solves a horizontal problem that many businesses could resell (CRM, scheduling, invoicing, analytics)
- Partners have existing customer relationships and distribution channels you cannot easily replicate
- The customization requirements are primarily visual, not functional
- You are comfortable with partners owning the customer relationship
It does not make sense when your brand is a core part of the value proposition, when deep product customization (not just visual) is required per partner, or when you want direct relationships with every end user.
If you are comparing this approach to building separate products for each partner, the custom development vs SaaS comparison helps frame the build versus platform decision.
Getting Started
The minimum viable white label platform needs: partner registration and configuration, basic branding (logo, colors, product name), subdomain or custom domain routing, data isolation between partners, and a partner management portal.
Start with subdomain routing (`partner.yourplatform.com`) before tackling custom domains. Start with shared database and row level isolation before offering dedicated infrastructure. Start with visual customization before offering feature level customization.
Build the partner experience first, then scale the number of partners. A white label platform that works beautifully for 5 partners will teach you everything you need to know to support 500.
White label SaaS is a powerful business model that leverages other businesses' distribution to scale your product. The architecture is more complex than standard SaaS, but the revenue model, where every partner is a distribution channel, makes the investment worthwhile. If you are exploring a white label strategy for your SaaS product, reach out to us and we will help you design the architecture.