Multi-brand platform · B2B & B2C

One platform, many brands: making a brand a matter of configuration

A white-label platform serving many operator brands had grown by copying — each brand its own build, its own configuration, its own styles. The work: turn a brand into configuration, so one codebase can serve many brands safely.

Product
Dashbet ↗︎
Context
NRGaming
Year
2023
My role
Own the shared multi-brand web application platform and its modernization
Before — a build per brand Brand A own configuration own stylesheets own build target Brand B own configuration own stylesheets own build target Brand C own configuration own stylesheets own build target modernization After — brand as configuration tenant config A Brand A tenant config B Brand B tenant config C Brand C One codebase one build config: theme tokens · layout variants · modules · assets · i18n
Simplified system view — for illustration

The product

Dashbet is a consumer sports and casino product in Tanzania, built mobile-first for its market. It is one of several operator brands running on NRGaming’s white-label B2B platform. Each brand has its own identity, navigation, enabled features, content and localization; underneath, they share one product, the same real-time data and the same backend services.

The problem

The platform had grown by copying. In the legacy setup every brand was its own build target, with its own project configuration, a large brand-specific configuration file, its own stylesheets, and build-time file replacement to swap brand-specific code in. Desktop and mobile versions of the same feature were often separate implementations.

That model is manageable with a handful of brands. With many, it becomes the bottleneck: a shared fix has to land in many places, brands quietly drift apart, and onboarding a new brand is an engineering project rather than a setup task.

What made it complex

  • Many brands in production at once. Any change to shared code can affect all of them.
  • Brands differ in real ways — layout, enabled modules, navigation, legal content, localization and assets — not only in color.
  • A live, real-time product. The platform can’t be paused while it is restructured.
  • Migration alongside delivery. Brands move over one at a time while feature work continues.
  • Backend dependencies. A brand can only move once the services it needs are available on the new backend gateway.

My responsibility

I own the shared web application platform the brands run on: its architecture, how brand-specific configuration, localization, branding and environment separation work, and its performance and production stability. I work with product managers, designers, backend engineers, QA and DevOps to turn operator requirements into platform capabilities rather than one-off brand changes.

Approach and key decisions

  • Brand as runtime configuration, not a build target. One codebase and one build. The brand is resolved at runtime from the domain and a tenant configuration, so adding a brand does not mean adding a project.
  • A small theming contract. A brand’s visual identity is reduced to a small set of tokens from which the full palette is derived, replacing per-brand stylesheets.
  • Layout variants selected by configuration. Where brands genuinely differ in structure, the platform offers numbered layout variants — header, sidebar, footer, mobile navigation — loaded on demand. A variant is built once and becomes available to every brand.
  • Code or configuration, decided up front. Each brand requirement is classified before estimation: configuration, assets, a layout variant, or a missing platform feature. Only the last two are code, and platform features are built once for all brands.
  • One responsive implementation instead of two. Separate desktop and mobile implementations are consolidated into responsive components.
  • Per-tenant assets and translations. Assets and localization resolve against each brand’s own hosts, so content can change without a release.

Constraints and trade-offs

  • Structure over pixel-perfection. Migrated brands keep their information architecture and page structure but adopt the shared component system — consistency chosen over a pixel-perfect copy of the old site.
  • Configuration has limits. Too much configurability turns the configuration into a second codebase. New layout variants are added only when a brand’s structure genuinely differs.
  • Replace rather than port, where it’s cheaper. The sportsbook is integrated through a provider SDK instead of carrying the legacy in-house implementation forward — less code to own, at the cost of less control over that part of the product.
  • Performance budgets stay fixed. An explicit bundle-size budget keeps shared growth from quietly slowing down every brand.

What changed

  • Brand work shifts from code to configuration: most of what makes a brand distinct is expressed as configuration and assets.
  • Shared features are built once and become available to every brand.
  • One responsive implementation per feature instead of parallel desktop and mobile code paths.
  • The migration continues brand by brand, without pausing feature delivery.

Technology

  • Angular
  • TypeScript
  • RxJS
  • WebSockets
  • Runtime tenant configuration
  • CI/CD
Dashbet — consumer product running on the shared multi-brand platform
Dashbet in production · dashbet.co.tz
Next case study
PMBet 2023 Real-time systems · B2C

Keeping a high-traffic, real-time product fast and stable while it keeps changing

A high-traffic consumer product with continuous live data, a catalogue of 900+ titles and a mostly mobile audience. The work: keep it responsive and stable while features, content and markets keep changing.

Role
Lead delivery of the client application — architecture, performance and production stability
Focus
Real-time data · Performance · Production reliability
Read case study →