WHITE-LABEL
One engineering team. Any number of independent brands.
Each installation configures its own look, its own languages, its own feature set, and generates its own encryption keys. Same codebase, genuinely separate products.
Five things a new project sets up without touching code.
Not one of these is a deployment. They are all settings.
01
Its feature set
Enable and disable from the catalogue. A content-only platform switches commerce off entirely; a shop leaves case management off. A disabled feature's API routes stop answering and it disappears from the menu, admin search, bulk actions, and dashboard — not hidden, absent.
02
Its branding
Colours, fonts, logo, text direction, default language. All from the admin panel, with no redeploy.
03
Its own security keys
Generated automatically on first run. No two installations share a secret, even on a shared codebase.
04
Its content and commerce model
Content types and custom fields defined as data. A new field needs no code and no database migration.
05
One public endpoint for the front end
A single call tells the front end which features are switched on and how to brand itself.
Right-to-left isn't an afterthought.
Text direction is a per-instance setting, not a plugin. So is the default language. An Arabic-language client and an English one run the same core with genuinely different presentation, and neither is the “special case” that breaks after an upgrade.
How multilingual worksA problem in one project never becomes a problem in another.
This is the part that distinguishes a white-label platform from a theme.
Separate keys
Every installation generates unique encryption and signing keys on first run. A breach in one cannot reach another.
Separate data
Separate deployments, separate databases. Nothing is shared by default.
Shared improvements
What they do share is the core — so a security fix or a new feature reaches every brand you run, without a merge.
Why this changes the economics.
The same portfolio of clients, run two ways.
| One codebase per client | One Quarkino core, N configurations |
|---|---|
| One codebase per clientEvery project needs its own infrastructure work | One Quarkino core, N configurationsInfrastructure is done once |
| One codebase per clientEvery fix applied N times | One Quarkino core, N configurationsA fix propagates |
| One codebase per clientUpgrades are per-project projects | One Quarkino core, N configurationsUpgrades are routine |
| One codebase per clientTeam knowledge fragments across repos | One Quarkino core, N configurationsA developer moving between clients is already productive |
Running more than one brand?
Tell us how many and how different they are. We'll tell you honestly whether one core fits.
- We reply within one working day
- No sales sequence, no drip campaign
- NDA before the call if you'd prefer