A copy per brand
- New repo or a long branch. Stores by hand.
Whitelabel: one codebase, several store listings
A fork per brand feels fast. A year later you merge the same bugfix three times. Brand as configuration is slower on day one and cheaper from variant three.
- Own branding, domain, store listing — one repo
- Build and release per brand, without copy-pasting the pipeline
Fork or variant
Configuration
- Same codebase. The wizard knows the brand.
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
Whitelabel starts harmless and ends as five almost-identical repos. The way out is boring and correct: names, icons and bundle IDs as data, not as git history.
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 9 September 2026. This comparison describes typical workflows and can differ from project to project. Logos are trademarks of their owners and are used only to identify the product.
When forks stay honest
- A genuinely different product If logic and roadmap diverge hard, a separate project is more honest than whitelabel.
Pricing model
You do not pay per fork; you pay the platform and the builds you actually trigger.
-
App StoreApple releases with prepared metadata and assets.
-
Google PlayPlay Store listings populated automatically.
Powered by Fastlane
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?
Yes. Each variant can have its own listings in the App Store, Play Store and Microsoft Store. The metadata editor walks you through the fields, screenshots can be cropped in place. Publishing runs through Fastlane.
Who is this for?
Mainly agencies selling a similar product repeatedly, and franchise structures where many locations need the same application under their own name. Software vendors offering partners a version in the partner's branding work the same way.
Who owns the code?
You do. Repositories, pipeline and deployment 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
Register for free, create a project and see how variants are configured and delivered.