What “white-label” actually means when you subcontract a developer

If you run an agency and you’re thinking about bringing in a white-label web developer, it really helps to know how the arrangement works day to day.

I spent five years employed at an agency, delivering client work under its name rather than my own. So I have seen this arrangement from the inside, as the person the work came to rather than the supplier it went out to. It was a remote agency, so working with a team I’m not sitting next to is normal for me. Now I’m independent, and I’m the developer an agency brings in.

It’s a really good way to work. The main difference between the three models isn’t the rate. It’s who owns the client relationship, and it’s well worth deciding that on purpose, right at the start.

The three models

1. Behind the scenes

I never appear. You brief me, I deliver to you, you deliver to the client.

The simplest setup for you, though questions take longer. Each one makes two hops: the client asks the account manager, the account manager asks me, I answer, and it goes back. A question that would take a few minutes on a call can take a couple of days, and a little detail tends to get lost on the way.

Great for clearly defined, self-contained work. Less suited to discovery work, where lots of small questions are the whole job.

2. Fronted under your brand

I join client calls with your name on the deck and your email address on my signature.

Fast, and the client gets a straight technical answer in the room rather than “I’ll check with the developer.” On a project with real uncertainty, this is worth more than any rate difference.

It needs you to trust that I won’t go around you, and it’s completely reasonable to want that in writing. I offer a non-solicit up front, so you don’t have to ask. Nobody should have to start a working relationship worrying about that.

3. Named subcontractor

The client knows there is a specialist involved and knows who.

Works well for technical SEO and migrations, where the client wants to hear the risk assessment from the person who did the assessment. It also protects you: if I say a migration needs another three weeks, that lands better coming from the specialist than from the agency asking for more time.

Who speaks to whom

The main difference between the three models is not the rate. It is who owns the client relationship, and how many hops a question makes before it comes back answered.

Two things to agree at the start

They’re the same two in every model, and neither is technical.

Who answers the client

When this isn’t clear, the developer waits for the account manager and the account manager waits for the developer. It is one of the early signs a project is drifting, and it is much easier to fix in week one than in week six. Nobody is doing anything wrong, but a two-day question can become a two-week one, and the client starts to feel the project is drifting.

Agree this before the scope, so it’s settled before the first client call. It takes one sentence: client questions go to [name], who answers directly / who briefs [name] within a working day.

What happens at the end

Who owns the code. Who holds the credentials. Who the client rings in March when something breaks.

Handover is part of the work, so it’s worth scoping like any other part. If it isn’t in the scope, it’s easy for it to slip, and the agency can end up looking after support it never priced for. Without a clear line, that support can quietly carry on long after the project ends.

Scope it explicitly, using something like the handover checklist, and price it. It’s often a day or two of work, and it gives everyone a clear finish line.

Case studies, and what I offer instead

White-label work carries someone else’s name. That’s the right arrangement, and it means most of what I’ve built belongs to other people. The sites are live and the clients are real, and I can talk you through any of it: what the job was, what it was built on, what went wrong and what I did about it. What I can’t do is put someone else’s site in a portfolio with my name under it.

So I’d rather give you something else to judge me on.

A written scope within 2 working days of the first call, before any money moves, so you can see how I think without hiring me. Something to see every week. A decisions log. And a handover written as if I won’t be around.

It isn’t the same as a portfolio, and I won’t pretend it is. It’s a real limit of working this way, and it’s fairer to say so. What it does mean is you can see the work taking shape from the first week.

When white-label isn’t the right fit

Two cases, and I’d say so on the call rather than take the work.

When development is most of what you sell. If the build is the product, your margin, your quality and your delivery reputation all rest on someone else’s availability. That’s a bigger decision than finding extra hands, and it’s usually worth hiring in-house.

When the work passes through more than one company. If the company you brief then briefs someone else, you’re two steps away from the people writing the code, and a little detail can get lost at each step. It’s always fine to ask directly who will be doing the work. With me, it’s just me. That keeps things simple, and it’s also a limit worth knowing about: one person can only take on so much at once.

While you’re asking, ask how long they’ve been at it. In my case: building websites since 2001, when I was 15, and doing it professionally since 2021. I’d rather you had both numbers than one rounded up.

What belongs in the contract

Short list, and none of it is unusual:

• Which model: behind the scenes, fronted, or named
• Who answers the client: and within what timeframe
• IP ownership: who owns the code on final payment, stated plainly
• A non-solicit: mutual, with a reasonable duration
• Confidentiality: covering what I see of your client’s business
• What handover includes: and that it’s a deliverable rather than a favour
• How a change gets quoted and who approves it
• Payment terms: and what happens when the end client pays you late
• How the engagement is framed, if the client is medium or large: what decides IR35 status is the client’s call to make, and it is better settled before the scope than after it

The one page to settle first

Nine lines, none of them unusual, and all of them easier before the first client call than after it. Two more beyond the seven here: how a change gets quoted and who approves it, and how the engagement is framed for IR35 if the client is medium or large.

The last one is easy to skip, and it matters a lot. Clients sometimes pay late, and that’s a normal part of agency life. Agreeing up front what happens when they do keeps everyone on good terms.

What it costs

I work at £400 a day, or £600 a day for evening and weekend work, as a fixed scope or a day rate, whichever suits the work. For comparison, the UK contract median for a senior web developer sits somewhere around £425–500 a day.

An agency day rate is naturally higher, because it also covers a project manager, an account manager, sales and a margin, and those are all part of what an agency gives its clients. I’m one person, so there’s no account layer to pay for. How you price the work to your client is entirely up to you.

How this works with me

• Pick the model on the first call, and I will tell you which of the three I would choose for that project and why. It takes two minutes and saves a fortnight.
• A written scope within 2 working days, before any money moves, so you can judge the thinking before you commit to it. That holds for every piece of agency work I take.
• A non-solicit offered up front, mutual, so you never have to ask for it.
• Handover written as if I won’t be around, priced as part of the job, so support does not quietly land back on you.