How Do You Let Customers Put Their Own Brand on Your Product?

How Do You Let Customers Put Their Own Brand on Your Product?

By exposing a small, fixed set of design tokens and refusing everything else. The teams that get white labelling wrong do it by allowing arbitrary CSS. The teams that get it right publish maybe ten variables, validate the values, and keep total control of layout and structure.

The request usually arrives from sales. An enterprise prospect wants the product to look like theirs, or wants to resell it to their own customers. The engineering answer, "sure, we will let them override the styles," is the one that costs you the next two years.

This is the framework we use, with the way two mature vendors have solved the same problem.

What Are You Actually Being Asked For?

Three different things wear the same label, and the first job is finding out which one. Light co-branding means your customer's logo and accent colour appear inside your product, and it still obviously looks like your product. Full white label means your brand disappears entirely and the end user believes it belongs to your customer. Embedded means your interface appears inside your customer's own application.

These have different costs by an order of magnitude. Co-branding is a week. Embedded is a product line. If someone in sales promised "white label" without specifying which, stop and pin it down before you estimate anything.

In our experience the honest answer is that most buyers asking for white label want co-branding. They want their logo on the login screen and their colour on the primary button, so it does not feel like a bolted-on third-party tool.

What Should You Expose, and What Should You Never?

Expose tokens. Never expose selectors. Stripe's Connect embedded components are a clean example of this discipline, because Stripe faces the harder version of the problem: its UI runs inside other companies' applications.

Stripe offers an appearance object with named variables, and the commonly used set is small: fontFamily, fontSizeBase, spacingUnit, borderRadius, colorPrimary, colorBackground, colorText and colorDanger. That is eight things, and it covers most of what a brand actually needs.

Then Stripe closes the door, in one sentence worth copying into your own documentation: "These options are the only way to change styles in Connect embedded components. You can't override their styles with CSS selectors or other mechanisms."

Why Is Allowing Custom CSS Such a Trap?

Because it makes your internal markup a public API you never agreed to support. Every customer stylesheet targets class names, and every refactor then becomes a breaking change for someone.

Auth0 states the problem from the vendor side with unusual candour. Its guidance warns that "CSS class names change each time Auth0 builds the project. Custom CSS that targets these classes will break with each new build," and separately that "The HTML structure of Universal Login pages is subject to change. Avoid customizations that rely on the HTML structure to prevent any interruptions."

Read that as a warning to your future self. If you allow CSS overrides, you will either freeze your markup forever or break paying customers on a Tuesday. Neither is a good outcome, and the second one arrives as a support ticket that looks like a bug in your product.

What Belongs in the Token Set?

Start with six and add only on evidence. Our default list is: a primary brand colour, a text colour, a background colour, a logo, a font family, and a border radius. That is enough for a product to feel like it belongs to someone else.

Add a danger colour if your product has destructive actions, because a customer's brand palette may make your red look wrong next to it. Add a spacing unit if your customers include design-led companies who will notice. Resist adding anything that changes layout, because layout is where your usability lives and your customers have not tested it.

Name the tokens semantically, not literally. A token called colorPrimary survives a rebrand. A token called blue500 does not, which is the argument we made in design tokens that survive a rebrand.

What Happens to Accessibility When Customers Pick the Colours?

It breaks, silently, unless you validate. This is the part most teams miss, and it is the part with legal exposure.

WCAG 2.2 Success Criterion 1.4.3 requires that "the visual presentation of text and images of text has a contrast ratio of at least 4.5:1," with large-scale text allowed 3:1. Success Criterion 1.4.11 requires 3:1 against adjacent colours for "visual information required to identify user interface components and states" and for parts of graphics needed to understand the content.

So when a customer sets a pale yellow as their primary colour and your button text is white, you have just shipped a failure on their behalf. Your product is the one being tested in their procurement review. Validate the contrast ratio at the point the token is saved, refuse or warn, and compute your button text colour from the supplied background rather than letting it be set independently.

Where Is the Line You Should Not Cross?

Anything that misrepresents where data goes, and anything legally required to be yours. A full white label that hides your identity entirely raises real questions: whose privacy policy applies, whose terms the end user accepted, who they contact about a breach.

There is a useful detail in WCAG here too. Success Criterion 1.4.3 exempts logotypes, stating that "text that is part of a logo or brand name has no contrast requirement." That exemption is about accessibility, not about disclosure. Removing your name from the interface does not remove your obligations.

Our practical line: the interface can be fully branded, and somewhere reachable, usually the footer or an about panel, there is a truthful statement of who operates the service. Sales will push back. Legal will thank you.

What About the Parts You Cannot Theme?

Name them in your documentation before a customer finds them. Every white label implementation has holes, and an undocumented hole becomes a support escalation.

Stripe does this explicitly. Its documentation states that some behaviour in embedded components, such as user authentication, "is always presented in a popup" and that "you can't customize the embedded component to eliminate such popups." That is not a limitation Stripe is hiding. It is a published constraint, so an integrator plans around it.

Your list will include things like transactional emails, error pages, the address in the email footer, third-party embeds, and anything rendered by a payment or auth provider you do not control. Write the list once. It is the single highest-value page in your white label documentation.

How Do You Give Customers Choices Without Giving Them Rope?

Offer options rather than values where you can. Stripe's overlays property is a good pattern: it "controls whether to use a dialog (also known as a modal) UI or a drawer UI for overlays," with valid values of dialog or drawer. Two choices, both tested, no way to invent a third.

Apply that everywhere you can. Logo position: left or centre. Density: comfortable or compact. Corner style: sharp, soft or round. An enumerated choice is something you can test and support. A free-form value is something you will debug.

Where you must accept a free value, like a colour, validate it hard and show the result immediately. A live preview is not a nice-to-have here; it is how the customer discovers their choice is bad before your users do. Put it in the same place as the rest of your configuration, following the patterns in designing a settings page.

Who Should Be Able to Change This?

Very few people, and not by accident. Branding is tenant-wide, so a mistake affects everyone in that account at once. Treat it like a destructive permission.

Our default is that branding sits behind an admin-only role, changes are logged with who and when, and there is a one-click revert to defaults. The revert matters more than it sounds: the fastest way to resolve a panicked support call about an unreadable interface is to restore the defaults while you work out what happened. That kind of scoping is the same problem as any other tenant-level setting, which we covered in roles and permissions UX.

Also decide whether changes preview before they publish. For a tenant with 2,000 users, they should.

What Is the Minimum Viable Version?

Logo, primary colour, and a validated contrast check, shipped behind an admin permission with a revert button. That is genuinely enough to satisfy most co-branding requests, and it takes a week rather than a quarter.

Build it as tokens from the start even if you only expose two, because the second request always comes. A product whose colours already flow from named variables can expose a third token in an afternoon. A product with hardcoded hex values in 200 components cannot, and that gap is the real cost of skipping the design system work, which is why we treat it as foundational in building a design system.

The thing to hold onto is that restraint here is a feature. Every token you do not expose is a support burden you do not carry and a refactor you stay free to make. Customers do not want infinite control. They want their logo, their colour, and for it to look deliberate.

If you are scoping this and want to avoid the expensive version, we are happy to talk it through. You can find us at phoenix.studio.