How white-label subcontracting actually works

Agencies rarely ask me how I write Drupal code. They ask what happens when their client asks a question in a meeting and the account manager does not know the answer. That instinct is right. In the years I have worked this way for US agencies, every problem worth remembering came from an artifact or a sentence, never from a commit.

I have also bought this arrangement. Before I worked as a subcontractor I ran a web agency as CTO and co-director, and I hired subcontractors for exactly the reasons my clients now hire me. The lesson from that side is the one I still work from, and it is not flattering to developers.

The subcontractor who caused problems was almost never the one who wrote worse code. It was the one who created work for the account manager.

What the agency is actually buying

An agency hiring a white-label developer is not buying hours. Hours are easy to find, in any timezone, at any price. It is buying the ability to say yes: to a Drupal upgrade, an accessibility remediation, a migration nobody on the team has run before, without hiring for it, without turning the work away, and without changing what the client believes about who is doing it.

That last clause is the entire product. Everything below is the operational cost of keeping it true, and it is mostly not technical.

The three places the promise leaks

White-label does not usually fail loudly. It fails in small disclosures that nobody planned, and each one costs the agency a little of the thing it was paying to protect.

1. The artifact leak

Names travel in metadata, and metadata outlives the project. A commit author on a repository the client eventually gets access to. The author field of an exported PDF. A screenshot pasted into a ticket with a browser profile or a chat sidebar visible at the edge. A README with a personal address in it. A code comment signed by hand three years ago.

Most of this is solved once, per repository, in two lines, and the point is that it is repository-local rather than global:

git config user.name "Agency Name"
git config user.email "dev@agency.example"

Then verify it, because the expensive version of this mistake is the one discovered at handover, in history that is already public inside the client organisation:

git log --format='%an %ae' | sort -u

Deliverables get the same treatment. Documents come to you in a format you can open and edit rather than one exported from a tool that stamps its own author into the file, and screenshots are cropped to the browser viewport before they go anywhere.

2. The language leak

A ticket update written for a developer does not read like one written for a client. If your project manager has to rewrite what I wrote before forwarding it, I have not absorbed work, I have added a translation step and put it on the person with the least time.

So everything I write in your tracker is written to be forwarded as it stands: what changed, what it means for the site, what happens next, and what I need from someone else. No internal shorthand, no version numbers without a consequence attached, and never the phrase “should be fine now”, which is not a status.

If your PM has to rewrite my update before sending it, I have added work rather than absorbed it.

3. The meeting leak

This is the one that actually breaks the arrangement. The client asks something reasonable on a call, and the person representing your agency cannot answer it. Once is nothing. Three times and the client quietly concludes that the team does not understand its own site, which is precisely the belief the whole arrangement exists to protect.

The fix is not that your account manager becomes a Drupal developer. It is that the predictable questions are already answered before the call. Ahead of any client-facing meeting where my work is on the agenda, whoever is running it gets a short brief: what changed since last time, the two questions most likely to come up with the honest answer to each, and one line on the risk nobody has asked about yet.

That last line is the one that earns its keep. A client hearing a risk from their agency before it happens reads it as competence. Hearing it afterwards, they read it as an excuse.

White-label and co-branded are different contracts

Full invisibility is not always the right shape, and pretending otherwise costs the agency money. Sometimes the client should meet me: a pitch where technical depth is what wins the work, a long discovery where relaying every answer through a third party loses detail, a live debugging session where the round trip costs more than the discretion is worth.

Which one applies is your decision, per project, and it can change while the project is running. It changes in one direction on its own: white-label becomes co-branded when you decide you want me in the room. It never moves the other way without you saying so, and I do not promote my own visibility, ever. If a client contacts me directly, you hear about it from me the same day, and I do not answer until you have told me how you want it handled.

What I need from you in return

This is the part I learned as the buyer rather than the seller, and it is where most bad subcontracting engagements were actually decided.

• One named person who can decide. Not a committee, and not a relay of what the client is thought to want.
• Access on day one. Repository, environments, a way to run the site locally. Waiting for credentials is the most expensive nothing in this business, and it is always billed to somebody.
• Your tracker, not mine. I work where your team already looks. There is no private board with the real status on it.
• The client context I am not allowed to ask for. Who actually uses the feature, what broke last time, what the client is quietly afraid of.

That last one is the genuine cost of white-label to you. I cannot ask the client anything, so every question about intent has to travel through your team. Agencies that carry those questions well get noticeably better estimates, because the expensive part of any Drupal estimate is never the code, it is the decisions nobody has the context to make.

Everything lives in your repository

The fear underneath all of this is rarely bad code. It is the subcontractor who goes quiet holding the only copy of how the thing works, on a project the agency has already promised to deliver.

So there is no private branch, no local-only script, and no step that exists only in my head. Work is committed while it is in progress rather than in one heroic drop at the end, anything non-obvious gets a paragraph in the repository next to the code it explains, and the deploy runbook is written for someone who has never seen the site, because eventually that is who will read it.

The timezone, honestly

I work from Antananarivo, which is UTC+3: seven hours ahead of New York, ten ahead of San Francisco. That is a real constraint and it is better said plainly than discovered in week two.

Your morning is my afternoon and evening, so a nine o’clock stand-up on the US East Coast is four in the afternoon for me, and I keep that window for anything that has to happen live. Outside it I am asleep, which is the part to plan around: live conversations get booked, everything else goes to the tracker.

The gap is not only a cost. Work happens while your office is closed, so a question written at five on a Tuesday afternoon usually has an answer waiting before nine on Wednesday. That only holds if the question is written well enough to be worked on without a follow-up, which is the same discipline as everything else on this page, pointed in the other direction.

What white-label is not

It is not anonymity that faces you. You know exactly who is doing the work: my name, nineteen years of history on drupal.org, and agencies who will take a reference call. The discretion is a service pointed at your client, not a fog between you and the person writing your code.

It is also not a staffing arrangement measured in bodies. One senior developer who understands why the client bought the project is worth more to an agency than three who are waiting to be told what to type, and considerably easier to keep invisible.

The discretion points at your client, never at you.