How a white label handoff works: NDAs, comms and who talks to the client

You have sold a build you cannot staff. There is a white label partner who says they will do it under your brand, the price works, and the only thing standing between you and signing is the question you have not said out loud: what stops these people from taking my client?

It is a reasonable fear and the honest answer is more specific than most partners give you. The usual answer is “we sign an NDA and stay invisible”, which sounds complete and is not. An NDA is a confidentiality agreement. It governs what somebody may say. It does not, on its own, stop anyone from calling your client next spring, and if that is the only document you signed, you protected your secrets rather than your revenue.

Here is how a white label handoff actually runs, clause by clause and day by day: what the partner needs from you, what your client sees, who holds the credentials at the end, and the two contract mechanics almost nobody writes about.

We can describe this from the inside rather than from a services page. About 60% of everything Green Wire Media has shipped since 2008 went out under someone else’s brand, across 800+ projects and 437 clients. The handoff below is the one we run.

What a white label handoff actually is

A white label handoff is the transfer of build work, not client ownership. You keep the client, the contract, the invoice and the relationship. The partner gets a scope, a deadline and access, and returns a finished site that carries your name.

The division of labour holds for the whole engagement:

Job	Who does it
Wins and owns the client	You
Quotes the client	You, marking up the partner’s fixed cost
Writes the brief	You, from what the client agreed
Builds and tests	The partner, under your brand
Presents the work, collects feedback	You
Fixes and iterates	The partner, from your consolidated notes
Holds domain, hosting and code	You or your client
Answers the client after launch	You, with the partner behind you

Everything difficult about a first handoff is a variation on one of those rows being unclear. If you want the money side of the same arrangement, we covered it in selling web development without a dev team.

Will the partner contact your client?

A working white label partner does not contact your client. Not for a quick question, not to clarify a design decision, not to check in after launch. Communication routes through you, staging links carry your brand, and the partner appears in a thread with your client only when you put them there.

That is the standard, and any partner worth signing will state it before you ask. What matters is which document holds them to it, because this is where most agencies leave a gap.

What the NDA covers, and what it does not

Three separate obligations get bundled under the word NDA, and only one of them is actually the NDA:

• Confidentiality (the NDA). The partner does not disclose your client’s identity, the project, the commercials, or their own involvement in the work. This is what you get by default.
• Non-solicitation. The partner does not approach, pitch, or market to your client, during the engagement and for a defined period after it. This is a separate clause. It is frequently missing.
• Non-circumvention. If your client finds the partner independently and asks to work with them direct, the partner declines or routes it back through you. Also separate, also frequently missing.

In our experience, an agency that has been burned by outsourcing was usually burned by the absence of the second or third clause rather than a breach of the first. Nobody leaked anything. The partner simply took a call they were never contractually barred from taking.

Ask for all three in writing before the first project, with the survival period spelled out. A partner who hesitates on non-solicitation has told you something useful for free. There is a fuller version of this vetting exercise in how to choose a white label WordPress agency.

Your partner is a sub-processor, and your client’s contract probably says so

This is the part missing from essentially every guide to white label handoffs, and it is the part with a regulator attached.

The moment your partner touches personal data belonging to your client’s users, they are a sub-processor under GDPR. Your client is the controller. Your agency, processing on their behalf, is the processor. The partner you engaged is another processor. That covers live database access, backups, hosting administration and most ongoing support, so it covers nearly every real engagement.

Two provisions decide what you have to do about it. GDPR Article 28(2) states that “the processor shall not engage another processor without prior specific or general written authorisation of the controller”, and that under a general authorisation you must inform the controller of any addition or replacement of processors and give them the chance to object. Article 28(3) requires the processing to be governed by a binding written contract setting out its subject matter, duration, nature and purpose.

Read plainly, that means your client has to have agreed in writing that you may use sub-processors, and you need a written data processing agreement with your partner. Most agency contracts already carry a general sub-processor permission. If yours does not, add one before the handoff rather than after.

It also means the “your client never knows anyone else exists” version of white label is not available for European clients. The partner can be invisible in your branding and your emails. They cannot be invisible in your client’s paperwork. Those are different kinds of invisible, and conflating them is how an agency ends up out of compliance while believing they are being discreet.

None of this is a problem in practice. Clients sign sub-processor lists with their hosting company, their CRM and their email provider without blinking. Disclosing that a named development partner works under your supervision reads as procedural, not as a confession, which is roughly the argument we made when we stopped hiding this work ourselves in the agency other agencies trust. Get the wording checked by whoever handles your contracts. The point here is to know the clause exists.

What the partner needs from you before day one

Handoffs fail at the brief far more often than at the code. A partner cannot ask your client a question, so anything you did not write down becomes an assumption, and assumptions become revisions you pay for.

Send all of it at once:

• Final design files with the states that are not in the file named: hover, empty, error, loading, and every breakpoint you actually care about.
• The sitemap and, per template, which parts the client will edit themselves.
• Content, or an explicit decision that placeholder content ships and real content follows.
• Integrations with credentials and sandbox access: CRM, payment, booking, analytics, newsletter.
• Hosting target, PHP version and WordPress version, agreed before the build rather than discovered at deploy.
• The deadline the client was actually promised, and which parts of the scope can move if something slips.

The last one gets omitted most and costs most. A partner who knows the real launch date can tell you in week 1 that it does not fit. A partner who learns it in week 4 can only apologise.

How communication runs once the build starts

One channel, one thread per project, one person on each side who is accountable. Slack Connect, a shared board, or email, in that order of usefulness. What matters is that there is a single place where a decision can be found later, not that the tool is fashionable.

Set two numbers before the build: the response time for a normal question, and the response time when something is broken on a live site. Those are different promises and a partner who quotes one number for both has not thought about it. Ours are stated because we have the record to state them: 5,000+ support tasks handled in the last 18 months, urgent edits turned around in 1-2 hours.

Your job in the loop is translation. Client feedback arrives as impressions and has to leave your desk as instructions. “It feels cramped on mobile” is not actionable; “reduce the section padding to 24px below 768px” is. Consolidate a round of feedback before you send it, rather than forwarding comments as they land, because a partner working from a moving target burns your margin, not theirs.

Staging, branding and what your client sees

Your client should see a site being built, on a URL that does not advertise anyone else. That means a staging environment on a neutral or your-brand domain, no partner logo in the admin, no partner name in code comments, page titles, or the theme header, and staging credentials issued to your agency rather than direct to the client.

Put the staging link in front of the client with the review scope stated in the same email: what you want feedback on now, and what is deliberately unfinished. An open-ended “here it is, thoughts?” invites feedback on things you did not budget to change.

Credentials, domain and code: who holds what at the end

Ownership at handover is the difference between a partnership and a hostage situation. Three assets, and the rule for each is the same: your client or your agency holds them, and the partner gets access instead of ownership.

The domain. Have the client or your agency register it. If the partner registers it in their own name and you later move the registrant to you, ICANN’s Transfer Policy allows the registrar to impose a 60-day inter-registrar transfer lock following a change of registrant, unless the holder opted out beforehand, and a registrar may refuse transfer of any domain in its first 60 days after creation. That is up to 2 months of not being able to move a domain, and you will find out exactly when you need it moved.

The hosting. Bought on your account or your client’s, with the partner added as a user. Access can be revoked in a minute; ownership takes a support ticket and a mood.

The code. In a git repository you own, written to a published standard rather than to one developer’s habits. The WordPress coding standards exist so that files “appear as if they were created by a single person” and any developer can modify them regardless of who wrote them. That is the practical test of a handoff: could a different developer pick this up next year without a rebuild? If not, you did not buy a website, you bought a dependency.

After launch: how support gets routed

The client emails you. You triage and route to the partner. The fix comes back and you send it, in your name, from your address. The client’s experience is that their agency handled it, which is true, because you did.

Agree the routing before launch, not the first time something breaks: where you send an urgent issue, what counts as urgent, what is inside the build warranty, and what is billable. Then decide whether you are reselling that support as a monthly plan rather than absorbing it as unpaid goodwill, which is the difference between a project that ends and an account that compounds. We covered the resale mechanics in white label WordPress maintenance.

When a white label handoff is the wrong call

It is the wrong call in three situations, and a partner who never says so is selling rather than advising.

If the project needs daily discovery with the client, a relay through you adds a day to every decision, and you should either run it in-house or put the partner in front of the client openly as your named development team. If the work is a 2-hour fix, the briefing costs more than the fix, so pay a freelancer or do it yourself. And if you have no margin left after the partner’s price, the deal was mispriced at the quote, not at the handoff. Walking away from that one is cheaper than delivering it. Our rates and the bands around them are in white label WordPress development pricing.

Quick answers

Will a white label agency contact my client directly? A working partner does not. All communication routes through your agency, staging carries your brand, and the partner never appears in a thread with your client unless you put them there. What legally stops them approaching your client later is not the NDA but a non-solicitation clause, so check that one is in the contract.

What should a white label development NDA cover? Three separate obligations: confidentiality (they do not disclose the client, the project, or their involvement), non-solicitation (they do not approach or market to your client), and non-circumvention (they decline if your client approaches them direct). An agreement with only the first protects your secrets and not your revenue.

Is a white label partner a GDPR sub-processor? Yes, whenever they touch personal data on your client’s site. Article 28(2) requires the controller’s prior specific or general written authorisation before you engage them, and Article 28(3) requires a written contract governing the processing. The partner can be invisible in your branding but not in your client’s paperwork.

Who should hold the domain and hosting after a white label build? Your client or your agency, never the partner. A change of registrant can trigger a 60-day inter-registrar transfer lock under ICANN’s Transfer Policy, and a domain can be refused transfer in its first 60 days regardless. Register and buy in your own name from the start, and give the partner access rather than ownership.

If you are about to run your first one

Get the three clauses in writing, add the sub-processor line to your client contract, register the domain yourself, and send the brief complete. Those four things prevent most of what goes wrong in a first handoff.

If you want to see what the output looks like before you trust anyone with a client, our work is largely other agencies’ projects with their names on them, and how we work with agencies sets out the contract terms above as our default rather than as something to negotiate.