White label app development: build vs runtime config

A white label app is one product, built once and presented under several brands, each with its own name, look, and sometimes its own behavior. The code is shared; the branding and configuration sit on top. The model shows up in retail holdings running multiple storefronts, in SaaS products resold under a partner’s name, and in franchise networks that need a branded app per location.

At the engineering level, this is a multi-tenant problem at the presentation layer. The same thinking behind architecting multitenant solutions — one system serving multiple tenants along a spectrum from fully shared to fully isolated — applies to a white-label frontend, where each brand is a tenant and the question is how much they share.

White label app development comes down to three architectures, each trading freedom against maintenance. Separate repositories give every brand its own codebase and total independence, at the cost of making every fix in every repo. Build-time configuration keeps one codebase and compiles a separate app per brand. Runtime configuration keeps one codebase and one app that adapts to each brand as it runs. Most teams reach for separate repos by reflex and pay the maintenance cost for years, so the real decision is usually between the two single-codebase approaches.

Build-time configuration keeps one codebase and compiles a separate app for each brand, selected by a build flag. A modern build tool makes this direct: with Vite’s env files and modes, a build command runs in a named mode, loads that mode’s variables, and statically replaces them in the output, so each brand’s build produces its own artifact carrying only its own configuration. This fits a specific shape of problem:

• the brands differ in ways fixed at build time — theme, feature set, default configuration
• shipping a separate artifact per brand is acceptable, such as separate deploys or app-store listings
• you want each brand’s bundle to contain only its own code, with the rest tree-shaken away

On the marketplace we built, a single React codebase generates several branded web applications through build target flags — among them VED.no, VEDASKOG.no, kortreistved.no, kortreistjord.no, proff.ved.no, and admin.kortreistved.no. Each is a distinct build of the same code, so a fix lands once and ships to all of them.

The risk with build flags is that they leak. A flag starts clean — one configuration value read in one place — and a year later there are ‘if (BRAND === X)’ checks scattered through components that have nothing to do with branding. The twelve-factor guidance on storing config in the environment frames the discipline: configuration that varies should live separate from code, not as constants sprinkled through it. Keep the brand differences behind a single configuration boundary, and let components read from that boundary rather than testing the brand directly.

If you are about to fork a repository per brand, it is worth checking whether build-time or runtime configuration would save you that maintenance tax first. Our e-commerce engineering team has built multi-brand apps with both approaches in one project, and can map the trade-offs to your brands.

Runtime configuration keeps one compiled app and decides the brand while the app runs, which fits when a single artifact has to serve every brand. The app reads its brand from outside the bundle:

• an environment variable or a config endpoint the app calls on startup
• the login response, when the user’s account determines the brand or product domain
• a feature-flag service, for differences that change without a redeploy

The mobile app on the same project takes this route. Its login response decides which product domain the app’s requests go to — the firewood marketplace or a separate garden-products brand — so one installed app serves more than one brand without a separate build for each.

On the web, runtime configuration can go further than values: with webpack’s module federation, brand-specific modules can be loaded at runtime from separate builds, so a host app composes the right brand’s pieces on the fly. That is heavier than reading a config object, and most white-label apps do not need it, but it is the tool when brands differ by whole features rather than by theme.

white-label-build-time-vs-runtime-config

Build-time configuration produces a separate artifact per brand, while runtime configuration ships one app that selects the brand as it runs.

Even inside one project, mobile and web can use different approaches, because their deployment models differ. A web app can ship a separate branded deploy per brand cheaply, which suits build-time configuration. A mobile app is an installed artifact, and shipping one per brand means separate app-store listings and review cycles, so serving several brands from one installed app through runtime selection is often the better trade. The same engineering problem gets two answers in one codebase, chosen per platform.

The mobile side has its own depth — push reliability, offline behavior, onboarding — covered in our piece on a supplier mobile app for a marketplace, and a companion piece on the delivery app’s build goes deeper on the runtime-selection approach.

Generally, no. White labelling is a common and legal model across software and retail. The questions that arise are contractual and intellectual-property ones: who owns the code, what trademark and brand-usage rights each party holds, and what the reseller or licensing agreement permits. Those depend entirely on how the agreement is structured. Bluepes is not a legal advisor, so treat this as orientation and consult counsel for any specific arrangement.

• White label app development has three architectures — separate repos, build-time config, and runtime config — and forking per brand is usually the most expensive to maintain.
• Build-time configuration compiles a separate app per brand from one codebase, which fits when brands differ at compile time and separate artifacts are acceptable.
• Runtime configuration ships one app that picks the brand as it runs, which fits when a single artifact has to serve every brand.
• Build flags leak if uncontained, scattering brand checks through the codebase; keep brand differences behind a single configuration boundary.
• Mobile and web can use different approaches in the same project, since their deployment models differ.

The architecture follows the brands rather than the other way around. When the difference between brands is fixed at build time and separate artifacts are acceptable, build-time configuration keeps each brand clean and lets a fix ship everywhere at once. When one artifact has to serve every brand, runtime configuration carries the brand decision into the running app. Separate repositories earn their place only when brands share almost nothing. Contain the flags, let mobile and web differ where their deployment models call for it, and most multi-brand work stays maintainable instead of multiplying.

If you are weighing how to build multiple brands from one product and want the architecture decided before the first commit, a short review will save months of rework. Talk through your white-label architecture.