---
title: "How to Build a White-Label SaaS Platform for Resellers in 2026"
author: "Nate Laquis"
author_role: "Founder & CEO"
date: "2027-03-03"
category: "How to Build"
tags:
  - white-label SaaS development
  - multi-tenant white-label platform
  - reseller SaaS architecture
  - custom branding SaaS tenants
  - white-label billing and domain mapping
excerpt: "White-label SaaS lets your partners sell your product as their own. Done right, it turns one codebase into a scalable distribution channel that prints recurring revenue."
reading_time: "14 min read"
canonical_url: "https://kanopylabs.com/blog/how-to-build-a-white-label-saas"
---

# How to Build a White-Label SaaS Platform for Resellers in 2026

## Why White-Label SaaS Is a Growth Multiplier

Building a great SaaS product is hard. Selling it is harder. White-labeling flips that equation by letting resellers, agencies, and partners do the selling for you. They slap their brand on your platform, mark it up, and sell it to their own customers. You collect recurring wholesale revenue without hiring a single salesperson.

This is not a niche strategy. Vendasta, GoHighLevel, Duda, and dozens of other platforms generate hundreds of millions in revenue by enabling resellers to rebrand and resell their software. The model works especially well for marketing tools, CRMs, website builders, reporting dashboards, and any vertical SaaS where agencies already serve the end customer.

The technical lift is real, though. A white-label platform is not just a SaaS app with a logo upload feature. You need per-tenant branding, custom domain mapping, reseller-level billing, strict data isolation, and admin dashboards at multiple levels. Skip any of these and your resellers will outgrow you fast.

This guide walks through exactly how to build a white-label SaaS platform in 2026, from architecture decisions to specific tools and vendor recommendations. If you have already built a standard SaaS product, start with our [guide to building a SaaS platform](/blog/how-to-build-a-saas-platform) for the foundational concepts.

![developer writing code for a white-label SaaS platform](https://images.unsplash.com/photo-1555949963-ff9fe0c870eb?w=800&q=80)

## Multi-Tenancy Architecture for White-Label Platforms

Every white-label SaaS platform is multi-tenant, but not every multi-tenant platform is white-label. The distinction matters because white-label adds a layer of hierarchy: you have your platform, your resellers (tenants), and their end customers (sub-tenants). That three-tier structure drives most of the architectural complexity.

### Choosing Your Isolation Model

You have three options for data isolation, and for white-label specifically, the middle ground usually wins:

- **Shared database, shared schema with tenant_id:** All resellers and their customers live in the same tables. A tenant_id column on every row separates data. This is the simplest to build and cheapest to operate. It works well if you have hundreds of resellers with thousands of end customers each.

- **Shared database, separate schemas:** Each reseller gets their own PostgreSQL schema. Better isolation, easier per-tenant backups, and simpler compliance storytelling. This is the sweet spot for most white-label platforms because resellers often demand proof that their data is logically separated from competitors.

- **Separate databases per reseller:** Maximum isolation, maximum operational pain. You will need automated provisioning, per-database migrations, and connection pooling across potentially thousands of databases. Only go here if you are selling to enterprises with strict regulatory requirements.

Our recommendation: start with separate schemas per reseller in PostgreSQL. Use a shared schema for platform-level data (reseller accounts, billing, domain mappings) and per-reseller schemas for customer data. This gives you clean isolation without the operational nightmare of managing hundreds of database instances.

### The Tenant Hierarchy

Your data model needs three levels. The platform level stores reseller accounts, global configuration, and platform billing. The reseller level stores branding, custom domains, subscription plans, and reseller-specific settings. The customer level stores end-user data, preferences, and activity. For a deeper dive on tenant design patterns, check our [multi-tenant SaaS architecture guide](/blog/multi-tenant-saas-architecture).

In practice, this means your database needs a resellers table, a customers table with a reseller_id foreign key, and row-level security policies that scope every query to the correct reseller context. Prisma and Drizzle both handle this well with middleware or query extensions that inject the tenant scope automatically.

## Custom Branding per Tenant

Branding is the entire point of white-labeling. Your resellers need the platform to look and feel like their own product. That means logos, colors, fonts, favicons, email templates, and login pages all need to be configurable per tenant, with zero code changes.

### What Needs to Be Customizable

At minimum, every reseller should be able to configure:

- **Logo and favicon:** Uploaded via the reseller admin panel, stored in S3 or Cloudflare R2, served via CDN with proper cache headers.

- **Color palette:** Primary color, secondary color, accent color, background color. Store these as hex values and inject them as CSS custom properties at runtime.

- **Typography:** Let resellers pick from a curated set of Google Fonts or upload their own. Loading arbitrary fonts at runtime is straightforward with the CSS Font Loading API.

- **Email templates:** Welcome emails, password resets, notifications, and invoices should all carry the reseller's branding. Use a templating engine like React Email or MJML with dynamic brand variables.

- **Login and signup pages:** These are the first thing end customers see. They must be fully branded. No "Powered by YourPlatform" unless the reseller opts in.

### Implementation Pattern

The cleanest approach is a theme configuration object stored per reseller in your database. When a request comes in, resolve the tenant (via subdomain or custom domain), fetch their theme config, and inject it into your application context. In Next.js, this works naturally with middleware that reads the hostname, queries the tenant config, and passes it through cookies or headers to your React Server Components.

Use CSS custom properties for runtime theming. Define your design tokens as variables, then override them per tenant:

**:root level:** Set default platform colors. **Per-tenant override:** Inject tenant-specific values via a style tag in your root layout. This approach avoids generating separate CSS bundles per tenant. One codebase, one deployment, infinite brand variations.

For images and assets, store them in a tenant-specific prefix in your object storage (e.g., /tenants/{tenant_id}/logo.png) and serve them through a CDN with the tenant ID in the cache key. Cloudflare R2 paired with Cloudflare CDN handles this with minimal configuration.

## Custom Domain Mapping

Subdomains are fine for getting started (acme.yourplatform.com), but serious resellers want their own domains. They want app.acmesoftware.com or dashboard.acme.io. Custom domain mapping is what separates a basic multi-tenant app from a real white-label platform.

### How It Works

The flow has four steps. First, the reseller adds their desired domain in their admin panel. Second, your platform generates DNS instructions (a CNAME record pointing to your platform's edge). Third, the reseller configures the DNS record with their registrar. Fourth, your platform verifies the DNS, provisions an SSL certificate, and starts routing traffic.

SSL provisioning is the part that used to be painful. In 2026, it is straightforward. Cloudflare for SaaS (formerly SSL for SaaS) handles automatic certificate issuance and renewal for custom hostnames. You make an API call to register the hostname, Cloudflare handles the rest. Vercel also supports custom domains per deployment, but Cloudflare gives you more control over caching, security rules, and edge logic.

### Tenant Resolution at the Edge

Every incoming request needs to resolve to a specific tenant before your application code runs. The resolution order should be: check if the hostname matches a custom domain in your domain_mappings table, then check if it is a subdomain of your platform domain, then fall back to a default or 404.

For performance, cache the domain-to-tenant mapping at the edge. Cloudflare Workers with KV storage is ideal for this. The worker intercepts every request, looks up the tenant from KV (sub-millisecond reads), and forwards the request to your origin with a tenant ID header. Your application never touches the database for tenant resolution on hot paths.

One common gotcha: wildcard DNS. You will need a wildcard DNS record (*.yourplatform.com) and a wildcard SSL certificate for your subdomain tenants. Cloudflare handles this automatically. If you are on AWS, use ACM with Route 53 and an ALB, but expect more manual configuration.

![team reviewing white-label SaaS platform architecture on a screen](https://images.unsplash.com/photo-1553877522-43269d4ea984?w=800&q=80)

## Reseller Billing and Subscription Management

White-label billing is more complex than standard SaaS billing because you have two billing relationships: you bill the reseller, and the reseller bills their end customers. Your platform needs to support both, ideally through a single billing infrastructure.

### Platform-to-Reseller Billing

This is the simpler side. You charge resellers on a wholesale basis, typically per-seat, per-customer, or usage-based. Stripe Billing handles this cleanly with subscriptions and metered billing. Common pricing models for white-label platforms include a base platform fee plus a per-active-customer charge, tiered pricing based on the number of end customers, or flat monthly licensing with usage overages.

Use Stripe's usage records API to report metered usage (active customers, API calls, storage consumed) at the end of each billing period. Stripe calculates the invoice automatically. For a complete walkthrough on subscription billing patterns, see our [guide to implementing subscription billing](/blog/how-to-implement-subscription-billing).

### Reseller-to-Customer Billing

This is where it gets interesting. Your resellers need to bill their own customers, and they need to control pricing, plan tiers, and payment collection. You have two approaches:

**Stripe Connect:** Each reseller gets a connected Stripe account. Your platform acts as the Connect platform, enabling resellers to create their own products, prices, and subscriptions within Stripe. Payments flow directly to the reseller's bank account, and you can take a platform fee (application fee) on each transaction. This is the gold standard for white-label billing because it gives resellers full ownership of their customer payment relationships.

**Platform-managed billing:** You handle all payment collection centrally and pay resellers via revenue sharing. Simpler to build but creates more liability and regulatory complexity. Only go this route if your resellers explicitly prefer not to manage their own payment processing.

Stripe Connect with the "Standard" or "Express" account type is the right choice for 90% of white-label platforms. Resellers onboard through a Stripe-hosted flow, your platform creates subscriptions on their behalf using the Stripe API, and Stripe handles payouts, tax reporting, and compliance. You collect your platform fee automatically on every charge.

## Data Isolation and Security

Your resellers are trusting you with their customers' data. If Reseller A can accidentally see Reseller B's customer data, you have a catastrophic breach. Data isolation is not optional and it is not something you bolt on later.

### Database-Level Isolation

If you are using the separate-schema approach in PostgreSQL, each reseller's data lives in its own schema. Your application sets the search_path at the beginning of every request based on the resolved tenant. This means even a bug in your application logic cannot leak data across tenants, because the database itself enforces the boundary.

For the shared-schema approach, PostgreSQL row-level security (RLS) is your safety net. Define policies that filter every SELECT, INSERT, UPDATE, and DELETE by tenant_id. Set the tenant context using SET app.current_tenant at the start of each database session. RLS policies run inside the database engine, so they cannot be bypassed by application code.

### Application-Level Isolation

Beyond the database, enforce tenant boundaries in your API layer. Every API endpoint should validate that the authenticated user belongs to the tenant they are requesting data for. Use middleware that extracts the tenant from the auth token and injects it into the request context. Every database query downstream uses that context. No exceptions.

File storage needs the same treatment. Tenant files should be stored under tenant-specific prefixes in S3 or R2 (e.g., /tenants/{reseller_id}/customers/{customer_id}/). Generate pre-signed URLs scoped to the correct prefix. Never serve files through a generic endpoint without tenant validation.

### Audit Logging

White-label resellers, especially in regulated industries, will ask for audit logs. Log every significant action: user logins, data exports, configuration changes, permission modifications. Store audit logs in an append-only table (or a dedicated service like Datadog or Betterstack) with the tenant ID, acting user, action type, timestamp, and affected resource. Make these logs accessible to resellers through their admin dashboard. This is a feature that closes enterprise deals.

## Admin Dashboards: Platform, Reseller, and Customer

A white-label platform needs three distinct admin experiences. Each audience has different needs, permissions, and workflows. Building all three well is what separates a sellable platform from a prototype.

### Platform Admin Dashboard (Your Team)

This is your internal control center. It should include reseller management (onboard, suspend, configure), global platform metrics (total resellers, total end customers, MRR, churn), billing oversight (invoices, failed payments, revenue by reseller), domain and SSL certificate status across all tenants, feature flag management for gradual rollouts, and system health monitoring. Build this with a framework like Retool or AdminJS for speed, or use your own component library if you need tight integration with your platform.

### Reseller Admin Dashboard

This is what your resellers log into to manage their white-label instance. It needs branding configuration (logo, colors, fonts, custom domain setup), customer management (add, remove, view activity), billing management (plans, pricing, invoices via Stripe Connect), usage analytics (active customers, feature adoption, revenue), team management (invite team members with role-based access), and white-label settings (custom email sender address, support links, terms of service URL). The reseller dashboard must itself be white-labeled. If a reseller's customer stumbles into the admin area, they should see the reseller's brand, not yours.

### Customer-Facing Application

End customers interact with the core product. Their experience should feel like a standalone application built by the reseller. The login page, dashboard, settings, and help center should all carry the reseller's branding. Customers should never know your platform exists unless the reseller chooses to surface a "Powered by" badge.

Build the customer experience as a standard SaaS application, but parameterize everything through the tenant context. Navigation labels, help links, support email addresses, and even feature availability can all be configured per reseller. This flexibility is what makes your platform valuable to a diverse set of resellers serving different markets.

![startup team working on a white-label SaaS admin dashboard](https://images.unsplash.com/photo-1504384308090-c894fdcc538d?w=800&q=80)

## Tech Stack, Timeline, and Next Steps

Here is the stack we recommend for building a white-label SaaS platform in 2026:

- **Frontend:** Next.js 15 with React Server Components. Server-side tenant resolution in middleware, runtime theming with CSS custom properties, and a single deployment serving all tenants.

- **Backend:** Node.js with tRPC or REST via Fastify. Tenant-scoped middleware on every request. Background jobs with BullMQ or Trigger.dev for async tasks like provisioning and billing sync.

- **Database:** PostgreSQL with per-reseller schemas. Prisma for migrations and type-safe queries. Connection pooling with PgBouncer.

- **Auth:** Clerk with multi-tenant organizations, or Auth0 with organization-level SSO. Both support custom domains and branding per tenant out of the box.

- **Billing:** Stripe Billing for platform-to-reseller charges. Stripe Connect (Standard or Express) for reseller-to-customer billing.

- **Custom Domains:** Cloudflare for SaaS with Workers for edge-based tenant resolution. Cloudflare KV for caching domain-to-tenant mappings.

- **File Storage:** Cloudflare R2 or AWS S3 with tenant-scoped prefixes and pre-signed URLs.

- **Monitoring:** Sentry for error tracking with tenant tags on every event. PostHog for product analytics segmented by reseller.

### Realistic Timeline

A white-label platform takes longer than a standard SaaS product. For a team of 3 to 4 engineers, expect 4 to 6 weeks for core multi-tenant architecture, auth, and database setup. Another 3 to 4 weeks for the branding engine and custom domain mapping. Then 3 to 4 weeks for Stripe Connect integration and reseller billing. Two to 3 weeks for admin dashboards at all three levels. And 2 weeks for testing, security review, and hardening. Total: 14 to 19 weeks from kickoff to launch-ready. That timeline assumes your team has built multi-tenant systems before. If this is new territory, add 30% for learning curve and architectural iteration.

### Get Started

White-label SaaS is one of the highest-leverage business models in software. You build one product and let an army of resellers distribute it. But the technical foundations matter enormously. Cut corners on tenant isolation, branding flexibility, or billing architecture, and you will spend months patching holes instead of signing resellers.

If you are planning a white-label platform and want to move fast without cutting corners, we can help. Our team has built multi-tenant, white-label systems across industries from marketing tech to fintech. [Book a free strategy call](/get-started) and we will map out the architecture, timeline, and costs for your specific platform.

---

*Originally published on [Kanopy Labs](https://kanopylabs.com/blog/how-to-build-a-white-label-saas)*