Branding

What you configure

The Dashboard section of the portal, branding panel:

• App name, storefront headline and subline.
• Logo, favicon, plus icon and splash for the mobile build.
• Colours: primary and accent, plus background, surface and text — or a ready preset theme.
• Support and legal: support email, links to terms, privacy, no-logs and refunds.
• Default locale for the storefront.

How it is applied

The storefront on your domain. Middleware resolves the brand from the request's domain and injects colours, logo and copy into the markup. No rebuild; changes are visible as soon as you save.

The mobile client. The brand arrives per account, not per domain: an installed app has no domain to resolve, and the same binary sits on the phones of every partner's customers. After sign-in the client fetches its brand and applies it; the result is cached to disk so a cold start does not flash our palette first. If a partner is suspended, branding switches off.

What the mobile client will not carry

• Your logo in a stock build. The connect screen has to render while the network is blocked, and an image that must be downloaded will be missing exactly when it matters most. The real logo ships only inside a branded build, compiled in.
• A full palette. The accent, the name and the mark on the connect screen are yours. Background and text stay on a neutral scale: a partner colour pair on a device we have never seen produces an unreadable screen far too easily.
• The support email and legal links do reach the client, but there is no screen to show them on yet.

Branded builds

Separate APK and IPA under your bundle id, with your icon, splash and name. We build them: we need a brand slug (immutable after first publish), a 1024×1024 icon, a 1242×2436 splash and a logo. One bundle id cannot belong to two partners.

We do not ship a single build with every brand inside: that leaks other people's assets and lets moderation of one brand take down all the rest.