Picture a branding agency with twelve people. Designers, two strategists, an account team. A long-standing client asks for a customer portal and a mobile app to go with the new identity the agency just delivered. The agency has never shipped an app. Saying no means a competitor gets a foot in the door. Saying yes means finding someone to build it.
This is where white-label development comes in: a software team builds the product, the agency presents it under its own name, and the client deals only with the agency. Done well, it lets a small agency offer far more than its headcount suggests. Done badly, the agency ends up as a middleman who can't answer technical questions, can't fix anything on a Friday evening and, eventually, loses the client to the people who actually wrote the code.
The difference is rarely the partner's skill. It is how the work is set up, run and handed over. Here are seven rules that keep the relationship yours.
1. Decide what "white-label" means before the first call
The phrase covers very different arrangements. In one, the partner never appears anywhere: no name in the code, no email to the client, no presence in meetings. In another, the partner joins calls as "our development team" under the agency's email domain. In a third, the partner is introduced by name but the contract and invoices go through the agency.
None of these is wrong, but mixing them causes trouble. If the partner's developer signs an email with their own company name in week six, the client will notice. Write down which model you are using, and agree on the details: which email addresses, which names on calls, whose name appears in the app store listing and in the code comments.
2. Keep the client relationship on your side of the table
The agency's value in this arrangement is the relationship: knowing what the client really wants, what they said last year, which stakeholder needs to be kept happy. Protect it.
- All client communication goes through the agency, even when the partner drafts the technical answer.
- The agency's project lead attends every client meeting, including the technical ones.
- Requests that arrive informally, such as a client messaging a developer directly, are routed back through the agency, politely and every time.
This is not about hiding information. It is about making sure that the person the client trusts is the person who can actually make commitments on scope, price and dates.
3. Write a brief a stranger could build from
Agencies are used to creative briefs, which leave room for interpretation. Development briefs can't. A partner who wasn't in the room needs to know:
- Who uses the product and for what. Roles, main tasks, rough numbers of users.
- What is in scope, and what explicitly isn't. "No payments in version one" saves a week of discussion later.
- Which systems it touches. Existing website, CRM, payment provider, login provider, analytics.
- What "done" looks like. Supported browsers and devices, languages, accessibility expectations, and who approves each milestone.
If you find you can't answer these questions, that is useful too. It means the client conversation isn't finished yet, and starting development now would only move the uncertainty into the invoices.
4. Own the accounts, the code and the keys
This is the rule that protects you if the partnership ends. Every account the product depends on should be in the agency's name or, better, the client's name with the agency as administrator:
- The code repository.
- Hosting and cloud accounts, domains and DNS.
- App Store and Google Play developer accounts.
- Third-party services such as email delivery, maps or payments.
The partner gets access, not ownership. When the project is finished, or if you ever need to change partners, you should be able to remove one set of permissions and carry on. If the code lives in the partner's private repository and the app is published under their developer account, you don't have a product. You have a dependency.
5. Agree on how bad news travels
Every project has a week when something goes wrong: an integration behaves differently from its documentation, a store review rejects a build, an estimate turns out to be optimistic. What matters is how quickly the agency hears about it.
Agree on a short weekly written update from the partner: what was done, what is next, what is at risk. Ask for risks to be raised as soon as they are known, not saved for the end of the sprint. Then decide together how each problem will be explained to the client. The agency should never learn about a delay from the client.
6. Plan for life after launch
The project doesn't end at launch. Someone has to apply security updates, renew certificates, respond when an operating system update breaks a screen, and answer the client's "small change" requests for the next two years.
Settle this before the contract is signed:
- Who monitors the live product, and who is called when it goes down?
- What response time does the agency promise the client, and does the partner's commitment match it?
- How are small changes estimated and billed after launch?
An agency that promises a four-hour response to its client while its partner promises next-business-day has a gap that will eventually show.
7. Insist on a handover you could actually use
At the end of each phase, ask for a handover package even if you plan to keep working with the same partner: a short document describing how the system is built and deployed, where configuration lives, how to run it locally, and which accounts and keys exist. Test it by asking someone who didn't build the product whether they could follow it.
This document is cheap to produce while the work is fresh and very expensive to reconstruct two years later. It is also what makes the agency's ownership real rather than theoretical.
In short
White-label development works when the agency keeps three things: the client relationship, the ownership of code and accounts, and a clear view of what is happening in the project. Decide on the model up front, write a brief a stranger could build from, keep every account in the right name, agree on how problems are reported, plan the years after launch, and ask for a handover you could actually use. The partner writes the code; the agency still owns the product and the promise.
Planning a project like this?
Plan it in 10 steps