Nicolás Duque

Turning a mobile app into a white-label SaaS

Feb 11, 2026 · 3 min read

At Doktor24 I worked on refactoring the mobile app into a white-label SaaS platform: one codebase that partners could launch under their own brand. The goal was to make onboarding a new partner a matter of configuration and a build, not a new project. We used configuration layers in the app and Bitrise for CI/CD.

The starting point

An app built for one brand has that brand everywhere: names, colors, icons, texts, feature choices, even small assumptions in the code. Launching it for a partner by copying it would give you two apps to maintain. Doing that a few times is how teams end up with several slowly diverging copies.

Configuration layers

The core idea was to separate what the app does from how a given partner's version looks and behaves, and to express the second part as configuration:

  • Branding: name, colors, typography, icons, splash screens.
  • Content: texts and links specific to the partner.
  • Features: which parts of the product are enabled for this partner.
  • Environment: which backend and settings a build talks to.

The app reads these layers instead of hard-coding them. A default layer defines the base product, and each partner's layer overrides only what differs.

Config vs code: where to draw the line

This is the decision that matters most. My rule of thumb:

  • If partners differ in values (a color, a text, a flag), it's configuration.
  • If partners differ in behavior that the product already supports, it's a feature flag in configuration.
  • If a partner needs new behavior, it's code in the shared product, built so other partners can turn it on too.

The trap is letting configuration grow into a programming language, or letting "just this once" partner-specific code land in the shared app. Both make the platform harder to change.

A build pipeline per brand

Mobile apps add a constraint web apps don't have: each brand is a separate app in the stores, with its own identifiers, signing and assets. So the pipeline has to produce one build per partner from the same code.

With Bitrise we set up CI/CD so that a build takes the shared code plus one partner's configuration and produces that partner's app. Onboarding a partner then means adding their configuration and assets, and running the pipeline.

Pitfalls to plan for

  • Testing combinations. Every feature flag multiplies the number of possible apps. Test the default product well, and test each partner's actual configuration before release.
  • Assets and store metadata. Icons, screenshots and store listings are per brand and easy to forget. Treat them as part of the partner's configuration.
  • Secrets and signing. Each brand needs its own signing setup, stored securely in CI, never in the repository.
  • Validation. A missing key in a partner's configuration should fail the build, not crash the app for users.
  • Drift. Review partner requests against the rule above, so the shared product stays shared.

What I'd recommend

  1. Start with a default configuration that is the real product, and make partners override it.
  2. Keep partner differences as data, and new behavior as shared, flag-controlled code.
  3. Make one pipeline build every brand, and validate configuration as part of it.
  4. Treat configuration with the same care as code: versioned, reviewed and tested.

That last point came back later in a very different domain. At KitchenSync we moved per-customer accounting rules into configuration for the same reasons; I wrote about it in Rules as data.