White-label web development: how it really works between agency and developer

White-label in web development means an agency delivers to its client work done wholly or partly by an external developer, under the agency's own brand. For the client, the supplier is the agency. It is a very common arrangement, and it works well on one condition: the boundaries are clear from day one. I work this way with many agencies; here is how I set it up.

Why agencies choose it

• Elastic capacity: handling peaks without hiring.
• Specific skills: an integration, an application, a migration the in-house team does not cover.
• Focus on their own craft: strategy, design, client relationship.
• Predictable costs: per-project or hours-based models.

Boundaries with the client

This rule is non-negotiable: the client belongs to the agency. The developer does not contact them directly, does not offer their own services and does not use side channels. When a direct technical discussion is needed, it happens in the way the agency decides: with them present, through an agency address, or by introducing the developer as part of the technical team.

Confidentiality and agreements

Before starting, in writing:

• a non-disclosure agreement covering materials, data and commercial information;
• no direct contact with the client, including after the project ends, for a defined period;
• ownership of code and rights, passing to the agency or client according to their contract;
• portfolio use only with explicit permission.

Code, repositories and accounts

This is where many collaborations crack months later. My approach:

• the agency's repository (or the client's), with the developer invited as a collaborator;
• accounts in the agency's or client's name: hosting, domain, external services, stores, API keys;
• credentials shared with secure tools, never by email;
• documentation sufficient for another developer to carry on.

If the developer vanished tomorrow, the agency must not lose anything.

The workflow

1. Brief from the agency, with goals, design and acceptance criteria (I cover this in How to write a brief for a developer).
2. Questions and estimate with assumptions and exclusions.
3. Development on branches, with readable commits.
4. Online previews on neutral addresses, which the agency can show the client with no reference to the developer.
5. Review by the agency, fixes, approval.
6. Release and an agreed support period.

Previews are the heart of the method: the agency checks the work at any time and decides what to show the client, and when.

Pricing models

• Per project, at a fixed price, when the scope is defined.
• By the day, when the work is exploratory or requests change.
• Ongoing, with a monthly budget of hours, when the agency needs stable development capacity.

Mistakes that ruin the collaboration

• Verbal agreements on scope and ownership.
• Access held in the developer's name.
• Communication that bypasses the agency "to save time".
• No visibility of the work until delivery.
• Estimates without assumptions, which turn into disputes at the end.

How to present it to clients

The agency has three ways of handling the external developer's presence, all legitimate:

• pure white-label: the developer never appears, and all communication goes through the agency;
• member of the technical team: introduced as part of the agency's team, joins technical meetings when needed, always with the agency present;
• declared partner: the agency presents the developer as an external specialist for part of the project.

The choice depends on the client and the type of project. What matters is consistency: decided at the start, kept to the end, respected even in the details (email addresses, signatures, names in repositories visible to the client).

A checklist before starting

• Confidentiality and non-solicitation agreement signed.
• Scope, acceptance criteria and pricing model in writing.
• Repository, hosting and services in the agency's or client's name.
• Staging environment and neutral preview addresses.
• Communication channel and contacts defined.
• Rules on portfolio and mentions.

My take

White-label work needs something beyond technical talent: quiet reliability. The agency stakes its reputation on work it does not do with its own hands, and must be able to trust without checking everything. That is why I propose the rules myself at the start: the agency's repositories and accounts, previews on neutral addresses, no contact with the client unless you decide so, no portfolio mention without permission. It is also why some projects I built for agencies do not appear among my work: the client is theirs.

One more thing I have learned over the years: white-label works best not as a stopgap for peaks but as an ongoing relationship. An agency working with the same external developer across several projects builds a real advantage: shared conventions, repositories set up the same way, more accurate estimates because they are based on work already done together, and a technical contact who knows the clients without ever having met them. That is why, where it makes sense, I suggest the ongoing model with a monthly budget of hours: it gives the agency stable development capacity and gives me continuity on the code, which is the best condition for doing it well. And when a project is not right for me, I say so straight away: for an agency, a clear no is worth more than an improvised yes.

Why work with me

I have been programming since 1999, delivered more than 300 projects and worked as an external developer with about 30 agencies, including white-label, from Rome and remotely. I fit into your processes and tools, and the relationship with the client stays yours.

If you have a project coming up or a peak of work, get in touch: a call of about 20 minutes to see how we can work together. How I work white-label is explained on the Collaborations page.