One Codebase, Ten Branded Apps: Notes From a White-Label Flutter Platform

Youth.ai is part of our team's experience: it was built by people now on the Nexentra team, before or independently of Nexentra. The Youth.ai case study covers the product. This article is about the architecture decision underneath it, because the same question comes up whenever a business wants more than one version of an app.

The problem with one app per brand

The business behind Youth.ai works with health and supplement brands, including Purovitalis Aura, Vitamins&Me, Cerva and Haus of Life. Each partner wanted its own app in the App Store and Google Play, with its own name, colours and store listing.

The obvious way to do that is to copy the project for every brand. It works for the second app. By the fourth, every bug fix has to be made four times, the copies drift apart, and nobody is quite sure which version has which feature. The cost of maintenance grows with every partner you sign, which is the opposite of what a platform should do.

Flavours instead of forks

The answer was a multi-flavour Flutter platform. There is one repository and one feature set. What changes from brand to brand is configuration:

• the brand's assets, icons and colours
• its own Firebase project
• its own bundle ID
• its own store metadata

Flavorizr generates the per-flavour setup, and environment-based configuration decides which brand a build is for. A new partner becomes a new configuration, not a new codebase. That's how one repository ships more than ten branded apps.

The discipline this needs is easy to state and hard to keep: brand differences live in configuration, never in brand-specific conditions scattered through the feature code. The moment a feature starts checking which brand it's running in, you're back on the road to separate apps.

Six screening providers, one experience

The health features rely on AI screening from six providers: Shen.AI, Canary Speech, Binah, Gero, MX Lab and Skinive. Between them they cover face, voice, skin and biological-age analysis. Each SDK has its own capture requirements. Some need the camera, some need audio, some need video.

Left alone, that becomes six different experiences glued together. Instead, the capture flows were designed as one journey. Users are guided the same way each time, whatever runs underneath, and results are presented consistently. People don't need to know which vendor measured what. They need to trust the result.

The unglamorous parts that make it work

A white-label platform is only as good as its release process. With ten or more apps, "we'll remember the steps" stops being an option. The platform has documented multi-brand release workflows, so shipping an update to every brand is a repeatable procedure rather than an afternoon of guesswork.

Around that sit the production essentials: Crashlytics for crash monitoring, Mixpanel for analytics, Intercom for in-app messaging, and StoreKit for in-app purchases and subscriptions. Features are organised in modules with GetX, which keeps state management predictable as the product grows.

When is a white-label app the right call?

It isn't always. A white-label platform pays off when:

• several products share most of their features
• the differences are mostly visual or commercial, not functional
• you expect to add more brands over time

If each brand needs substantially different features, separate apps sharing a common library can be cleaner. Either way, it's a decision worth making deliberately at the start. Moving from copied projects to flavours later is far more painful than starting with flavours.

Purovitalis Aura is one of the branded apps built on this platform. If you're planning several apps from one product, our mobile app development work starts with exactly this kind of architecture decision.