White-labelling: making the platform yours

Everything that carries a brand — the admin, both mobile apps, payment descriptions, push notifications — is yours to change. This page is the whole list, in two parts, because the two parts work very differently.

The one thing to understand first

You have to rebuild the apps anyway. Every buyer publishes to their own Google Play and App Store account, under their own package name — that is not something a server can change remotely. So the build-time list is not a limitation of this platform; it is what shipping your own app means. What this platform does is make it one file and one command instead of a hunt through source.

Part 1 — Runtime (no rebuild)

Admin → Settings → Branding. Set three things:

• Brand name — appears in the admin, on the login screen, on both apps' welcome screens, in wallet and referral copy in every language, and as the merchant description your riders see on their card statement.
• Primary colour — one hex. The admin derives its whole 50–900 palette from it, and both apps derive their accent, tints and gradients from it. The Settings page previews the derived ramp live before you save.
• Logo URL — shown in the admin sidebar, on the admin login screen, and on both apps' welcome screens. The shipped mark is used when you have not set one.

That is the whole runtime story. Save, reload, done.

On languages: the brand name is injected into translations rather than baked in, so "SpeedGo Wallet" renders correctly in Tamil, Bengali, Arabic and the rest, with each language's own word order.

Part 2 — Build-time (brand.config.json)

One file per app, at mobile/rider/brand.config.json and mobile/driver/brand.config.json:

{
  "name": "SpeedGo",
  "scheme": "speedgo",
  "iosBundleId": "com.speedgo.rider",
  "androidPackage": "com.speedgo.rider",
  "brandColor": "#e11d48",
  "icon": "./assets/icon.png",
  "adaptiveIcon": "./assets/adaptive-icon.png",
  "splash": "./assets/splash-icon.png",
  "logoMark": "./assets/brand/logo-mark.png"
}

Admin → Settings → Branding will generate this file for you, pre-filled with the colour and name you chose. Drop it into the app folder.

Build it

cd mobile/rider
npm run brand:check          # catches problems before the store does
npx expo prebuild --clean
npx expo run:android         # or eas build

brand:check fails the build on the mistakes that are expensive to discover late: a bundle ID that is not valid reverse-DNS, an icon that is not square or is under 1024px, a JPEG renamed to .png (builds fine, renders black), a missing asset, a malformed colour. It warns — without failing — if you are still on our default bundle ID, because that one is unrecoverable after your first publish.

The artwork you need

The shipped icon.png is a placeholder and identical in both apps. Ship distinct, real icons — stores reject two apps with the same icon, and your drivers and riders cannot tell them apart on a home screen.

Environment overrides

Every field can be overridden by an environment variable, which wins over the file — for CI and EAS build profiles that build several brands from one checkout:

APP_NAME · APP_SCHEME · IOS_BUNDLE_ID · ANDROID_PACKAGE · APP_ICON · APP_ADAPTIVE_ICON · APP_SPLASH · APP_ICON_BG

Resolution order is env → brand.config.json → shipped default. See each app's ENV.md for the non-branding variables (API URLs, Maps key, EAS project).

What is deliberately not branded

The dispatch console's dark "ops" surfaces stay ink navy in every install. That is a mode, not a brand — a control room should read as a control room — and your accent colour rides on top of it. Everything else follows your brand.