What are you actually delegating?
Technical execution is the visible part. What you really delegate is the promise your agency made to its client: the deadlines, the quality, and — if something breaks — the explanation. Your client does not know a third party exists, and that is precisely why the risk is yours.
So the criteria that work are not the ones you use to hire a vendor. They are the ones you use to bring on a team: how they work, how they communicate, and how they respond when there is a problem.
Which criteria predict the outcome best?
| Criterion | What to ask | The answer that should worry you |
|---|---|---|
| Communication channel | Who talks to the end client? | “We can talk to them directly to move faster” |
| Incident response | What happens if something goes down outside business hours? | A generic answer with no response time and no one accountable |
| Ownership of accounts | Whose name do the accounts and licenses sit under? | The vendor’s |
| Documentation | What do I get besides the deliverable? | “The code speaks for itself” |
| Continuity | What happens if we end the relationship? | There is no handover plan |
| Confidentiality | Can the project be mentioned in your portfolio? | They assume yes by default |
What are the most reliable red flags?
- They want direct contact with your client “to move faster.” The intention may be good, but it erodes your position and, at worst, it is the first step toward working with them without you.
- There is no master agreement, only quotes. Without one document covering confidentiality, ownership of the work, and liability, every project is negotiated from scratch and none of them covers what matters.
- Reluctance to document. A partner who does not document is making you dependent, whether they realize it or not.
- A portfolio shown without permission. If they show you other agencies’ work by name and in detail, they will show yours the same way.
- They only talk about technology. A partner who never asks about the end client’s business will build exactly what you asked for, including when what you asked for is wrong.
What should the agreement say?
Five clauses prevent almost every conflict that actually comes up:
- No competing for your clients during the relationship and for a reasonable period afterwards.
- Two-layer confidentiality: the client’s information, and also the fact that the subcontracting exists.
- Ownership of the work: the code, the designs, and the documentation belong to your agency or to your client, depending on what you agreed with them.
- Service levels with response times: incident response, not only delivery dates.
- An exit plan: what gets handed over, and how long it takes, if the relationship ends.
The fifth is the one most often left out, and the one that costs the most.
How do you test a partner without risking an important account?
With a small real project, not an artificial test. A narrow assignment with a date — one specific integration, a landing page wired to the CRM — reveals in two weeks what a portfolio does not show: how they estimate, how they tell you when something slips, and what they do when a requirement nobody mentioned shows up.
What you are watching for is not whether the deliverable came out well. It is how they behaved when something went wrong, because in a real project something always does, and that is exactly what you are buying.
When does White Label make sense, and when should you hire in-house?
White Label makes sense when demand for that capability is intermittent, when you need to cover several disciplines that do not each justify a salary, or when you want to move into a type of project without committing to a hire before you know the market is there.
Hiring in-house makes sense when that capability is the core of your offer and you use it every week. The practical rule: what differentiates you stays inside; what merely enables you can be delegated. We work as a White Label technical team for agencies in precisely the second case, with the end-client relationship staying in the agency’s hands.