SaaS White-Labeling Capability. @saas-white-labeling

White-labeling is how a SaaS product becomes a channel business: partners and enterprise customers sell or deploy your product under their own brand. The naive route — a forked deployment per partner — collapses under its own maintenance within a year. The SaaS White-Labeling Capability builds it as configuration instead: one codebase, one deployment, many brands.

The finish state is a product that wears each tenant's identity end to end — their logo, colors, domain, and email sender — configured per tenant from an admin surface, with your engineering unchanged by partner number twelve arriving.

Tenant Branding

Logos, color themes, and product naming applied per tenant through a theming layer — bounded so partner brands cannot break your interface.

Custom Domains

Partners on their own domains with automated verification and certificate management — plus the auth, cookie, and redirect handling multi-domain SaaS actually requires.

Branded Email

Transactional email in the tenant's identity: templates, sender domains with DKIM/SPF, and deliverability that survives leaving your domain.

Presentation Config

The configurable surface beyond colors — feature visibility, terminology, login pages, onboarding content — defined per tier so white-label becomes a sellable plan capability.

1. Scope — Fix the brandable surface, the domain and email architecture, and which capabilities each plan tier gets.
2. Build — Land the theming and configuration layer, domain and email automation, and the admin surface for managing it.
3. Handover — First partner brands live in production, the partner-onboarding runbook handed over, and the capability wired to your plans.

The SaaS White-Labeling Capability is a menu item on the Scrums.com delivery catalog, available at every plan tier. Add it to your plan backlog and your delivery team schedules it like any other item — scoped, tracked, and reported through the SEOP. See Delivery Plan Tiers.

How much can partners customize?

As much as you decide to expose — that boundary is a scoping decision, not an accident. The theming layer enforces it, so partner brands express identity without being able to degrade the product experience you are accountable for.

Does onboarding a new partner brand need engineering?

No — that is the success criterion. A new brand is configuration: assets uploaded, domain verified, emails authenticated, all through the admin surface and runbook, in hours rather than sprints.

What does this assume about our architecture?

Sound tenancy underneath: brand configuration is per-tenant data. If isolation is not yet structural, the Multi-Tenant SaaS Foundation item comes first, and the two schedule cleanly back to back.