White-label builds for agencies
Your client never finds out, because there is no way for them to find out
We build and QA experiments as your execution arm, inside your process and under your NDA, with every preview link, QA sheet, bug report and commit produced unbranded at the point it is made.
The arrangement is structural rather than promised: we have no access to your end-client stakeholders at all. Nobody here can contact them by mistake, by initiative, or in the middle of an incident.
- Your NDA signed before the first brief
- The variation code is yours, throughout and at exit
The problem
How white-label arrangements actually get exposed
Nobody is exposed by a supplier introducing themselves. It happens through artefacts and reflexes, in small moments nobody planned, and almost always in one of these four ways.
The artefact with a logo on it
A QA sheet, a preview link or a bug report forwarded in a hurry, carrying somebody else’s branding into your client’s inbox. Recoverable, and not comfortable.
The commit history
A name, an email domain or a company handle in a commit message, a code comment or an error monitoring payload. Nobody looks, until a technical client does.
The ambiguous brief
A build hits a question the brief did not answer. The fastest way to resolve it is to ask the person who knows, and the person who knows is your client.
The incident at nine in the evening
Something breaks, your client asks you what happened, and you cannot answer without going through somebody. That gap is where arrangements come apart.
Invisibility is an operating discipline rather than a promise: unbranded artefacts by default, no route from us to your client by construction, and answers that reach you fast enough that the gap never shows.
What unbranded actually has to cover
Most white-label promises cover the deliverable and stop there, which leaves the exposure exactly where it usually happens. Everything an agency might reasonably forward to a client has to be produced clean at the point it is made, because anything that needs sanitising before it is sent will eventually be sent before it is sanitised.
| Artefact | How it stays clean |
|---|---|
| Preview and staging links | Hosted on neutral or your own domains, never on ours, and named for your project rather than our ticket |
| QA sheets and test evidence | Produced in your template if you have one, unbranded if you do not. Forwardable without an edit |
| Code and commit history | No name, email domain or company handle in comments, commit messages or authorship |
| Bug reports and questions | Written to be read by your client, so you can pass one on rather than translating it first |
| Error monitoring and logs | No payload, tag or endpoint that identifies a third party to anybody inspecting the page |
| Documentation and handover notes | Written as though your team wrote them, because as far as your client is concerned your team did |
The row people forget is the last one, and it is the one that matters longest. A build gets forwarded once; documentation sits in your client’s systems for years and is read by whoever arrives next. Anything that reads as though it was written by an outside supplier is a question waiting to be asked at the least convenient moment.
Why there is no route from us to your client
The strongest form of a promise is an arrangement in which breaking it is not available. So this one is structural rather than behavioural: the engagement gives us no access to your end-client stakeholders at all, which means nobody here can contact them by mistake, by initiative, or in the middle of an emergency.
That has a cost and it is worth being straight about it, because it is the thing that occasionally frustrates a build. Every ambiguity in a brief has to come back to you rather than being resolved at source, and you are sometimes relaying an answer you have to go and get. The alternative is a route to your client that exists and is merely promised not to be used, and a promise not to use a route is worth considerably less than not having one.
We sign your NDA before the first brief rather than at contract stage, which is a small piece of sequencing with a real consequence: the first thing you send can be a genuine client brief rather than a sanitised approximation of one, and briefs that have been sanitised are the ones that produce the ambiguities in the first place.
Access to the store itself is scoped as narrowly as the work allows and is granted by you rather than negotiated with your client. Where a build genuinely needs a level of access you would rather not grant, we would rather say the build is not possible on those terms than acquire access through a conversation your client would have to be part of.
What we build
How the arrangement runs
Invisible by construction
- Your NDA signed before the first brief, so the first thing you send can be the real one
- No access to your end-client stakeholders at all, which is a structure rather than an undertaking
- Every artefact produced clean at the point it is made, never sanitised before sending
Inside your process
- Briefs arrive in your format and builds land on your board, rather than you adopting a system for our convenience
- Each build held to your QA tier where you have one, and to ours where you do not
- Questions written so you can forward them, not translate them
Yours to keep
- Readable, commented variation code, yours mid-engagement and at exit
- Nothing in comments, commit history or monitoring payloads that identifies anybody but you
- Documentation written as though your team wrote it, because that is where it will live
Roster hygiene
- Separate credentials, boards and documentation per client, with no shared library across them
- Method travels between accounts, material never does, including what worked for somebody else
- No consolidation onto one testing platform, because a client’s tool is usually their decision
What happens when something breaks
This is the moment that decides whether a white-label arrangement is real, and it is the one almost never covered before it happens. A variation misbehaves on live traffic, your client notices, and they ask you. Every second you cannot answer is a second the arrangement is visible.
Two things make that survivable, and both are decided long before the incident. The first is that every build fails safe by construction, so the visitor gets the original page rather than a broken one, which turns an emergency into a problem. The second is that you are given enough to answer immediately: what the change touched, how to turn it off yourself, and what the fallback does, handed over at launch rather than looked up during the incident.
- A kill switch you can operate yourself, without us and without waiting for a time zone
- What each build touches, written down at launch rather than reconstructed under pressure
- A written explanation you can forward, so the account conversation is yours to have
- The fix, when it needs one, delivered the way everything else is: unbranded and ready to pass on
The point is not that nothing ever breaks, which would be a promise no supplier can keep. It is that when it does, you are never the person who has to say they will find out and come back.
Several clients, kept apart
An agency rarely arrives with one client. It arrives with a roster, and a roster introduces a failure mode a single engagement does not have: material from one client reaching another, or reaching us in a way that mixes them.
So accounts are kept separate rather than merged into one convenient workspace. Separate credentials, separate boards, separate documentation, and no shared library of previous work that could carry one client’s approach into another’s build. It is slightly less efficient and that inefficiency is the product.
What travels between them is method rather than material: the QA standard, the fallback discipline, the way tracking is verified. What does not travel is anything specific, including the observation that something worked for another client, which is a genuinely tempting thing to volunteer and is not ours to offer.
Platforms are handled the same way. You are not asked to consolidate a roster onto one testing tool for our convenience, because a client’s platform is usually their decision and sometimes their contract, and an agency that has to renegotiate that before it can use a supplier has been handed the supplier’s problem.
How it runs
From your brief to your client’s approval
The loop is built so nothing has to route through your client, and so you are never the person waiting to find out.
- 1
NDA, then the real brief
Your NDA is signed before anything is sent, so the first brief can be the genuine one. Sanitised briefs are where ambiguity comes from, and ambiguity is what creates a reason to ask your client something.
- NDA before the first brief, not at contract
- Access scoped narrowly and granted by you
- Account set up separately from any other client
- 2
Questions come back to you
Anything the brief leaves open is written as a question you can forward as it stands. Where we can proceed on a stated assumption rather than blocking, we do, and the assumption is flagged rather than buried.
- Questions written for your client to read
- Assumptions stated, never silently made
- Nothing routed outside you, ever
- 3
Build and QA, unbranded throughout
The build runs to your QA standard with the evidence produced in a forwardable form. Preview links sit on neutral or your own domains, and nothing in the code or its history carries a name.
- Preview links never on our domain
- QA evidence forwardable without an edit
- No identifying mark in code, commits or monitoring
- 4
Handover and the kill switch
You get what the build touches, how to turn it off yourself, and what the fallback does, at launch rather than during an incident. Then the account conversation is entirely yours to have.
- A kill switch you can operate alone
- Behaviour documented at launch, not later
- The code is yours, mid-engagement and at exit
What white-label does not mean here
Three clarifications, because the term is used loosely enough that agencies are right to check.
It does not mean a reseller arrangement where you mark up a product you cannot inspect. You get the code, it is readable and commented, and it is yours mid-engagement and at exit rather than at some later point on good behaviour. Code you cannot take with you turns a supplier into a switching cost, and an agency depending on one has quietly acquired a risk it cannot see.
It does not mean we take over the relationship. Strategy, the verdicts and the account are yours; what you are buying is execution capacity. We do not produce recommendations for your client, and we do not put a point of view into a deliverable that you then have to defend or contradict.
And it is not a paid upgrade. This is the standard arrangement when an agency is the buyer, not a tier with a premium attached, because a supplier charging extra to stay invisible has misunderstood which of you has the client relationship.
Where this sits
This page is about how the arrangement works. The commercial side of it, how capacity is bought and what a first brief looks like, lives on hire an A/B test developer, which is the parent of this page and answers the same question for every other kind of buyer.
The work itself is A/B test development, and the narrower pieces an agency most often subcontracts have their own pages: tracking and QA validation when a result needs to be trusted before it is presented, server-side experiments when the browser cannot reach the change, and experiment analysis and readouts when the build is done and the readout has to survive a client asking hard questions about it.
The answers to your questions.
All of them, produced clean at the point they are made rather than sanitised before sending, because anything requiring an edit before forwarding will eventually be forwarded without one. That covers preview and staging links, which sit on neutral or your own domains; QA sheets and test evidence, in your template where you have one; bug reports and questions, written for your client to read directly; code, commit history and comments; error monitoring payloads; and handover documentation. The last one matters longest, since it lives in your client’s systems for years.
It comes back to you, always, because the engagement gives us no route to your end-client stakeholders at all. That is the cost of the arrangement being structural rather than promised: you sometimes relay an answer you have to go and get. To keep that from slowing a build, anything we can proceed on with a stated assumption gets built with the assumption flagged rather than blocked, and the question itself is written so you can forward it as it stands instead of translating it first.
You answer them, immediately, without going through anybody. Two things make that possible and both are settled before launch rather than during the incident: every build falls back to the original page rather than a broken one, so it is a problem instead of an emergency, and you are given a kill switch you can operate yourself plus a written note of what the build touches and what the fallback does. When a fix is needed it arrives unbranded like everything else. You are never the person who has to say they will find out and come back.
Yes, and they are deliberately kept apart rather than merged into one convenient workspace: separate credentials, separate boards, separate documentation, and no shared library of previous work that could carry one client’s approach into another’s build. Method travels between accounts, the QA standard and the fallback discipline; material never does, including the observation that something worked for another client, which is tempting to volunteer and is not ours to offer.
No. A client’s testing platform is usually their decision and sometimes their contract, so an agency forced to renegotiate it before it can use a supplier has been handed that supplier’s problem. We build natively in the major platforms and work across a roster running different ones simultaneously. The same applies to process: briefs arrive in your format, builds land on your board, and each build is held to your QA tier where you have one rather than to a workflow you would have to adopt.
No. It is the standard arrangement when an agency is the buyer rather than a tier with a premium attached, because a supplier charging extra to stay invisible has misunderstood which of you holds the client relationship. It also is not a reseller arrangement: you get readable, commented variation code that is yours mid-engagement and at exit, not at some later point conditional on good behaviour. Code you cannot take with you turns a supplier into a switching cost.
Need build capacity your client never sees?
Tell us how many clients you run, which platforms they sit on and what your QA standard looks like. We will tell you how the loop would work inside your process.
Talk through the arrangement ↗