Use Build-Time Branding for Resellers and Runtime Branding for Customers

A multi-app platform should not use one branding mechanism for every scenario.

Reseller branding and customer branding are different problems and should be handled differently.

A reseller usually receives a distinct release with its own product identity. That branding belongs at build time.

A customer usually shares the reseller's deployed application but needs a limited visual identity of its own. That branding belongs at runtime.

Trying to solve both with only build-time branding creates too many releases. Trying to solve both with only runtime branding creates unnecessary complexity and weakens the product boundary.

The cleaner model is a two-layer branding architecture:

a build-time reseller brand that defines the product identity;
a runtime customer theme that applies a controlled visual overlay.

That distinction should shape the design system, deployment pipeline and configuration model from the beginning.

Reseller Branding Defines the Product

Reseller branding is usually broad.

It may include:

product name;
application icon;
logo;
primary and secondary colours;
typography;
desktop installer assets;
browser metadata;
email templates;
support links;
legal or footer text.

These values affect the identity of the application itself. They may also need to be embedded into native binaries, installers and static assets.

If each reseller receives a separate build, the correct solution is to make the reseller brand a build input.

dotnet build -p:Brand=Acme

The selected brand folder can contain the tokens and assets used across the product suite:

DesignSystem/
  Brands/
    Default/
      tokens.json
      logo.svg
      brand.json
    Acme/
      tokens.json
      logo.svg
      brand.json

A build step stages those assets into the fixed resource paths expected by every application.

The applications remain unaware of the reseller. They consume semantic tokens such as PrimaryColour, ProductLogo and ApplicationName.

That preserves one codebase and one shared design system.

Customer Branding Is an Overlay

Customer branding is usually narrower.

A customer may want its own logo, colours and possibly typography inside the application. It normally should not be able to rename the product, replace legal text, alter navigation or change the reseller's application identity.

That makes customer branding a runtime concern, but it should be a constrained one.

The reseller build provides the baseline design system. When a customer signs in or a tenant is resolved, the application loads a customer theme containing only approved overrides.

For example:

{
  "logoUrl": "/branding/customer-123/logo.svg",
  "primaryColour": "#2457A7",
  "secondaryColour": "#E8EEF8",
  "fontFamily": "Inter"
}

The runtime layer should override semantic tokens, not component styles.

That means the same button, form and navigation components continue to behave identically. Only the values behind approved design tokens change.

This is important. Customer branding should personalise the product, not fork the user experience.

Use a Clear Precedence Model

The branding hierarchy should be explicit:

platform defaults
    ↓
reseller build-time brand
    ↓
customer runtime overrides

Each layer should only override values it is allowed to control.

The reseller layer can define the complete product identity. The customer layer can override a limited allowlist such as:

customer logo;
primary colour;
secondary colour;
accent colour;
approved font family;
optional light and dark variants.

Everything else should fall back to the reseller brand.

This prevents incomplete customer themes from creating broken or inconsistent interfaces.

Do Not Load Arbitrary CSS

Allowing customers to upload raw CSS is tempting, but it is usually a mistake.

Arbitrary CSS can break layouts, hide controls, weaken accessibility and behave differently across applications. It also creates a support problem because every visual defect may be caused by customer-supplied styling.

Customer branding should be data, not executable presentation logic.

Use a validated schema with known fields. Convert those fields into CSS variables, XAML resources or equivalent design tokens.

Reject invalid colours, unsupported fonts and missing assets before activating the theme.

Handle Runtime Differences Deliberately

Desktop, server-rendered and client-rendered applications will load customer branding differently.

A server-rendered web application can resolve the customer and inject tokens before rendering the first page. A single-page application should fetch the branding manifest before mounting the main interface to avoid a flash of reseller colours. A desktop application can load the customer theme after authentication and replace the relevant resource dictionary.

The loading mechanism can differ, but the schema and token names should remain consistent across the suite.

A shared branding contract is more valuable than forcing every application to use the same runtime implementation.

Fail Safely

Reseller branding should fail the build when required assets are missing.

Customer branding should fail back to the reseller theme when runtime configuration is missing or invalid.

Those are different failure modes because the risks are different.

An invalid reseller build should never ship. An invalid customer theme should not prevent the customer from using the application.

The system should log the problem, reject the invalid override and continue with the reseller defaults.

The Result

This two-layer model keeps the architecture aligned with how the product is actually sold and deployed.

Resellers receive distinct products built from the same codebase.

Customers receive controlled personalisation without requiring separate releases.

The design system remains the single source of truth, while branding becomes structured data with a clear precedence order.

Reseller branding defines the product.

Customer branding personalises it.

Treating those as separate concerns is what keeps whitelabelling scalable.