Most white label agreements are signed quickly, because by the time the paperwork appears the agency has usually already sold the project and wants to start. That urgency is exactly why the clauses that matter later get skimmed now.
This is not legal advice, and the terms that matter to you will depend on your jurisdiction and how your agency is structured. What follows is the set of questions worth resolving before signing, based on the things that cause disputes.
Client protection: what is actually promised?
This is the fear behind every white label conversation: that the partner will end up working with your client directly. Ask exactly what the agreement says, and be alert to the difference between a working practice and a contractual obligation.
A stated practice of not contacting your clients is genuinely meaningful — it describes how the company operates. But it is not the same as a non-solicitation clause, and a provider who blurs those two in conversation is telling you something. If formal protection matters to you, ask for it in writing rather than accepting reassurance, and get the scope right: which clients, for how long, and covering what conduct.
- Who at the partner is permitted to contact your client, and under what circumstances
- Whether the partner may approach your client after the project ends, and for how long
- Whether the restriction covers the client approaching them, which is a different and harder case
- What happens if your client independently finds them, which does occur
Code ownership and when it transfers
Two things to separate here: whether you own the work, and when. Many agreements assign ownership only on full payment, which is reasonable. Some assign it on final payment of the entire engagement rather than the project, which can leave you without rights to a finished site while a later phase is disputed.
Also ask what is excluded. Partners often retain rights to reusable components, internal libraries and tooling, which is normal and usually fine. What is not fine is discovering that a core part of your client's site is licensed rather than owned, with a licence that ends when your relationship does.
Who is liable when something goes wrong
Your contract is with your client; theirs is with you. If a bug causes real damage — a broken checkout during a campaign, a data exposure — you are the one being sued, and your recovery depends entirely on what the back-to-back agreement says.
Look at the liability cap. Many agreements cap liability at fees paid, which for a small project can be far below the exposure. That may still be acceptable, but you should know it rather than discover it. Ask about professional indemnity cover, and whether it extends to work delivered on your behalf.
Confidentiality that runs both ways
An NDA that only binds you is not unusual and should be pushed back on. You are handing over client names, commercial terms and often the pricing you charge. That deserves the same protection you are being asked to give.
Check whether the partner may reference the work in their own portfolio or case studies. A white label arrangement where the partner later publishes the build as their own is not white label, whatever the agreement calls itself. If they want the right to reference it anonymously, that can be a reasonable middle ground — but agree it now, in writing, not after they have published.
What happens when a deadline slips
Most agreements are silent on this, which means the answer is decided in the moment by whoever is angrier. Worth agreeing up front: how much notice you get when a date is at risk, what information comes with it, and whether there is any remedy attached to a missed date.
Be realistic about remedies. A penalty clause on a fixed-price web build tends to produce defensive estimating rather than faster delivery — you get padded timelines instead of honest ones. Notice and transparency are usually worth more to you than compensation.
Change control, and who decides what is in scope
Scope disputes are the most common source of friction on fixed-price work, and they are avoidable with one agreed mechanism: anything that changes the shape of the project gets flagged to you with a time and cost impact before it is acted on. You then decide whether to absorb it or raise a change order with your client.
What you want to avoid is either extreme — a partner who silently absorbs changes and resents it, or one who bills for every clarification.
Exit: the clause nobody reads
- Notice period on both sides, and whether it differs
- What is handed over on termination: code, credentials, documentation, staging and deployment access
- Whether handover is included or billable, and if billable, at what rate
- Who holds hosting, domain and third-party service accounts during the relationship — these should be in your name or your client's, never the partner's
- What happens to work in progress that is paid for but unfinished
That fourth point causes more trouble than the rest combined. Accounts held in a partner's name are a practical hostage even when nobody intends them that way, and untangling them under time pressure is unpleasant.
The signal in how they respond
How a prospective partner reacts to these questions tells you nearly as much as their answers. A team that has run this arrangement seriously will have positions ready, will say plainly which points are negotiable, and will tell you where their standard terms are simply their preference rather than a requirement.
Defensiveness about ownership, vagueness about client contact, or reluctance to put a stated practice in writing are all worth taking seriously at this stage, when walking away is still cheap.
For context on how these terms sit inside a working relationship rather than a document, how agency partnerships work covers the engagement models and what changes as one moves from a pilot to something ongoing, and our own position on NDAs, client contact and handover is set out under building under your agency's brand.
