Solution

White label apps without forking the project for every brand

A product shipping under several brands quickly turns into branches, copies and hand-maintained store listings. The platform treats brands as configuration and handles build, deployment and release.

One codebase, multiple brands with their own look
A dedicated domain and store listing per variant
Build, deployment and store release automated per brand

Start for free. No credit card required.

Shared codebase Live Timetable

One Flutter project. Many independent apps come from it.

KVB Live Timetable
iOS Android
MVG Live Timetable
iOS Android
RMV Live Timetable
iOS Android
HVV Live Timetable
iOS Android
VVS Live Timetable
iOS Android

You define variants in the project; build and release run per brand.

In short

Brands are configuration, not copies of the project.

One codebase: every feature is built once and becomes available to all brands.
Individual appearance: branding, domains and store listings differ per variant.

Managing variants yourself versus running them on the platform

This shows the work that multiple brands create and how the Application Platform consolidates it.

Task	With the Application Platform	Set up manually
Adding a new brand	Fully covered: Configure a variant in the project; build and deployment follow automatically	Not offered: Copy the repository or branch off and adjust it
Rolling a feature out to every brand	Fully covered: Build it once and the pipeline delivers it to all variants	Not offered: Back-port the change into each copy, conflicts included
Branding per brand	Fully covered: Colours, logos and copy belong to the variant configuration	Partly covered: Assets swapped by hand, usually right before a release
A domain per brand	Fully covered: Domain, DNS and SSL are part of each variant’s setup	Partly covered: Configured individually, with certificates to keep an eye on
Store listings per brand	Fully covered: Metadata, screenshots and changelogs maintained per variant	Not offered: Every app maintained separately across two or three portals
Signing across many apps	Fully covered: Android keystores and Apple credentials managed per variant	Not offered: A growing pile of certificates with no shared home
Backend and configuration	Fully covered: Environments and variables live as configuration in the project	Partly covered: Separate server and config states per brand, hard to compare
Attributing errors to a brand	Fully covered: Error tracking with Sentry, filtered by repository	Partly covered: Reports merge together or go missing for some variants
Knowing what is deployed where	Fully covered: Deployments appear as release cards per repository	Not offered: A spreadsheet or somebody’s memory of which brand runs what
Handing a brand over to a client	Fully covered: Repositories and configuration are yours, with full code ownership	Partly covered: Depends on how carefully the copies were documented

Green means fully covered, amber partly, grey not offered. The gap widens with every additional brand.

As of 10 August 2026. This comparison describes typical workflows and can differ from project to project.

What makes white label projects manageable

The parts that keep the cost of each additional brand low.

Variants instead of forks

Brands are configured inside the project, so no copy of the codebase drifts off on its own.

Domains and SSL per brand

Every variant gets its domain and certificate. Reverse proxy and SSL are part of the server setup.

Store listings per brand

Metadata, screenshots and changelogs are maintained per variant and published through Fastlane.

One release path

Organisations, roles and project credentials decide who can see and ship which brand.

Setting up a white label project

Four steps from the first brand to the tenth.

Create the base project

Pick your stack, for instance Flutter for mobile or Next.js for web. Repository, structure and pipeline come with it.
Define the variants

Add the brands to the project and record branding, domain and the differences in configuration.
Add store access

Signing material and store credentials are managed per variant so releases do not depend on one person.
Ship and keep up

Build a feature once. The pipeline delivers it to every brand, and you track the state per repository.

Frequently asked questions

How is this different from forking per client?

A fork splits the codebase permanently; every fix has to travel back into each copy afterwards. In a white label project brands stay variants of one codebase, differing in configuration, branding and store listings.

Can brands differ in functionality?

To a degree, yes, through variant configuration and centrally held environment variables, as long as differences remain expressions of a shared product. If two brands grow into different products, a separate codebase is more honest.

Does every brand get its own store listing?

You do. Repositories, pipeline and GitOps configuration live in your project, and the platform holds nothing back. Hand a white label product to a client, and the state can be delivered without rebuilding proprietary pieces.

Add the second brand without a second project