B2B2C · White label

How did one database flag become a second product?

Members of a reseller's employer groups could not use an app that already worked for them, because the company selling them the service could not show whose app it was. A rebranded copy on the same backend took two months, and monthly active users grew by half.

Health Samurai, for a US health insurance administrator · 2026 ·
My role
Spotted the opportunity and proposed it. Wrote the requirements and the login and matching logic together with the tech lead, and made the product calls along the way.
Team
The same team of seven that built the main member app
Timeframe
Two months from proposal to the stores
The constraint
The reseller's clients could never learn whose service they were really using.

If you only read one thing

A reseller sold our client's services under its own brand, so its employer groups were not allowed to download our client's app, even though they sat in the same database. We had to turn them away at login. I proposed a rebranded copy of the app on the same backend. It shipped in two months, the reseller paid for it, and monthly active users grew by about 50%.

The situation

Our client administered health plans for employers in the US, and we built its member app: claims, coverage, ID cards, finding a doctor in the network. More than 400 employer groups used it.

Part of the client's business came through a reseller, which sold the same services to its own employer groups under its own name. Those members were in the same database and had the same benefits. The only difference was one attribute on the group. But the reseller's clients could not know who was behind the service, so they could not be sent to an app with our client's name on it.

So the app turned them away. Even when a member from a reseller group entered correct details, we deliberately did not match them to their record. Everything they needed was already built, and we were blocking it.

The fork

The idea itself was simple: if the backend already works for these members, give them the same app under the reseller's brand. The real decision came next: how to build it.

Option A

Hardcode one copy

Fork the app, swap the logo and colours by hand, ship it. Fastest for this one reseller, and every future one would mean doing it all again.

Option B · chosen

Build a white-label tool

One codebase that can produce a branded app from configuration, so the next reseller is a setup job, not a project.

This reseller was not a one-off: selling under someone else's brand is common in this market. We gave up some customisation to get there: a brand gets what the tool supports, not anything it asks for.

What shipped

From the outside it looks like one feature flag. In practice it was a list of decisions, and agreeing them with everyone involved was harder than building them.

Client's app client's groups Reseller's app reseller's groups Login check which app? which group? Same backend one database
Two apps, one backend, one login check.

Who gets in where. One login flow for both apps. The backend recognises which app a request comes from and allows or refuses the match depending on the member's group. A member of a reseller group gets nothing from the client's app, and the other way round.

People move. Members change jobs, leave a group and join another one with the same email. Each of these moves had to land the person in the right app without losing their account. These edge cases took more time than the rebranding itself.

What a brand can change. I defined what the tool configures and what stays fixed, so a new brand never means new code.

Where it is published. We prepared the options; the client chose to publish both apps from its own store accounts.

What happened

2 monthsfrom proposal to the stores
+50%monthly active users, soon after launch
1backend for both apps

The reseller liked it, the client liked it, and the reseller paid for the development. Members who had been turned away at login could finally use what had been built for them all along.

What it cost

Customisation. Choosing a tool over a hand-made copy means a brand can only change what the tool exposes. For this reseller that was enough. A partner who wants their own features or flows would need a different conversation.

The takeaway

Before building something new, look at who you are turning away. Sometimes the product already exists and the only thing missing is permission to give it to them.

All cases Press & papers