An agency can outsource development without hiring, on one condition: who does what must be written down before the build starts. The agency keeps the client relationship, the brief, the brand and final sign-off. The technical partner scopes, builds, tests and documents. The partner's name never appears on the work, and the code belongs to the agency or its client.
When an agency needs developers but can't hire for one project
The scenario never changes. A good client shows up. The project is interesting. The team is already booked. Hiring for a single project costs too much and takes too long. Saying no sends the client to a competitor.
This isn't a sign of poor planning. According to one specialist provider, the most common reason agencies outsource development is simple: demand swings more than in-house capacity does, and a fixed team can't absorb every peak. A whole market has grown around that need.
So finding someone isn't the hard part. The hard part is knowing who does what. We see these projects fail for the same three reasons every time: the subcontractor ends up talking directly to the end client, the code stays on the subcontractor's accounts, or "it's tested" never says tested against what.
A new client, a busy team and a date that won't move: the 2026 World Cup
An agency had just signed a new client. Its team was committed to other projects. The launch had to line up with the 2026 World Cup. That date isn't negotiable: the opening match won't be pushed back because a feature ran late.
The agency asked us whether we could take on the build.
We didn't give a date straight away. First, we read the brief and listed what we didn't know. Then we put our questions in writing, to the agency and only to the agency. Whatever was still unclear became a short, scoped, paid first phase. An estimate built on gaps is a number the agency sells to its client and nobody can hit.
Next, we split the scope into two columns: what must be live at kickoff, and what can come after. That second column saved the schedule. The agency presented the split to its client in its own words, and the client approved it.
The project shipped with time to spare before the deadline. The end client only ever saw one name: the agency's.
How we work white-label with agencies: roles, NDAs and code ownership
At Pillet Grenié Bureau, we put the split of roles in writing before the first day of the build. It's the core of how we support agencies with development.
What the agency keeps
The client relationship, the brief, the brand and final sign-off. We never write to the end client, and we don't attend meetings under our own name. When a technical decision needs explaining, we prepare the explanation in business terms, and the agency's project manager presents it. They should be able to defend it without calling us mid-meeting.
What we do
We scope the work, make the technical decisions and explain them. Then we build, test and document. Our name doesn't appear in the delivered code, on any screen, or in the emails the application sends.
NDAs and code ownership
When the end client requires a non-disclosure agreement, we sign it. On ownership, one legal point matters more than the rest. A French legal analysis points out that white-label work doesn't create its own legal framework: the agency is still bound to its client by its own contract, and it can only transfer the rights it has actually acquired. If our contract with the agency doesn't assign the code to them, the agency is promising its client something it doesn't own. So we spell it out in writing.
Discretion doesn't mean secrecy. The same source notes that when France's 1975 subcontracting law applies, the subcontractor must be accepted and its payment terms approved, and that personal data rules may require naming everyone involved in the chain. We ask every agency to check these points with its own legal counsel. Better to do it before signing than in the middle of a dispute.
Handover day: checking the code really belongs to the agency and everything still works
A guide on choosing a subcontractor lists three confidentiality checks: no direct contact with the end client, delivery under the agency's brand, and full return of all work to the agency. The first two are handled during the project. The third plays out on handover day, and that's when silent failures show up.
We watch for two in particular.
Deployments that stop without warning. When the code moves to the agency's account, hosting can stay tied to the old location. The site stays live. But later changes never get published, and no error appears. The agency finds out three weeks later, when its client asks why the promised fix isn't showing. So after every transfer, we publish a small change and confirm it's actually live.
Emails that stop sending. The sending domain is tied to a single account. Moving it means renewing access for every sender: the application, but also the tool that sends login emails. Miss one, and sign-up confirmations stop going out on launch day. We send a real email from the new account before we call the handover done.
We also hand over the list of what our tests cover. We don't say "everything works." We say "tested against this list." A passing test only proves what it checks. The agency needs to know where that proof ends.
Handover is complete when five conditions are met: the accounts are in the name of the agency or its client, the documentation is delivered, a change published after the transfer is live, a real email has gone out, and our own access has been removed. That last point sometimes surprises agencies. For us, it's the best proof that the code is truly theirs.
