Ship it as your own product

Resell push.tt under your own name, or apply your enterprise's identity for internal use. Same platform, same encryption, your branding.

Try for free Contact us

Partly shipping. Runtime branding ships today: an organisation's product name and accent colour are applied on the Android app after sign-in, and the console additionally takes an uploaded icon for its logo and favicon. A separate reseller build with its own app-store listing is not built yet — the tenant model it will sit on already exists on the server.

The console branding panel: product name, accent colour and icon upload

Two ways to put your name on it

They solve different problems, and only one of them needs an app-store listing. Most enterprises want the first and assume they need the second.

push.tt

The default. Everything beside it is the same platform with a different identity applied — not a fork, not a separate codebase.

Your company

Enterprise branding. Your product name and accent colour applied at sign-in. No separate build, no store review, live the moment you save it.

FieldComm

Reseller tenant. Your own name, icon and store listing, over your own namespace of users, orgs and channels. In development.

What branding controls today

Three fields, set in the console by an org administrator and applied at runtime. There is nothing to rebuild and nothing to redeploy.

Product name — replaces "push.tt" through the app chrome and the console title
Accent colour — the app derives a full gradient ramp from it, so a blue-branded org does not get an orange gradient sitting on a blue button
Icon — an upload that becomes the console's logo and favicon. Content-addressed, so a new upload actually busts the browser's favicon cache

Honest limit: the Android launcher icon is not org-branded — changing it means a separate build, which is the reseller path below rather than a settings toggle.

Tenants: your own namespace

A reseller build is not a skin over a shared user list. A tenant is its own namespace of users, organisations and channels, and sign-in is scoped to it — two tenants can both have a user called "dispatch" without ever seeing each other.

Users, orgs and channels all carry a tenant, and every query is scoped by it
Each tenant carries its own default product name and colour, applied before anyone signs in
Your customers are your customers — they never see a push.tt sign-in screen

The tenant model is implemented on the server and exercised by the test suite. What is not built is the packaged client build and store listing that would sit on top of it.

What white labelling does not change

The encryption, deliberately. This is worth being blunt about, because "white label" sometimes implies a level of access that would break the product.

Channel keys are still generated on member devices and sealed to each device — a reseller does not hold them, and neither do we
Your customers' private and org channels stay unreadable to you, exactly as they are unreadable to us
An organisation can escrow its own keys for compliance, but that is the organisation's decision and its members are shown it

If your business model requires reading customer traffic, push.tt is the wrong platform and we would rather say so on this page than in a contract negotiation.

What is not built yet

Stated plainly so it can be planned around, rather than discovered during onboarding.

A packaged reseller app build and its own app-store listing
Per-tenant billing, and self-service tenant provisioning
A custom launcher icon on the handset app, which depends on the packaged build

Want to resell it?

Tell us what your customers need and which of the two paths fits. We will be straight about what is ready now and what you would be waiting on.

Talk to us