White Label Web Development: What to Agree Before the First Build

Of all the work agencies hand to a partner, development is the most common - and the easiest to get wrong, because the gap between "it looks finished" and "it is finished" is where most disputes live.

What do you hand over, and what do you keep?

The usual split: you keep the client, the strategy and the design; the partner builds. Some studios hand over design too, but the ones who keep it tend to be happier, because design is where their brand value sits.

Whatever the split, write down who owns which decision. "Who chooses the CMS" is a question worth answering before the kickoff rather than in week four.

What should the scope document contain?

• Page list and templates, counted. "About 12 pages" becomes 19 by launch.
• CMS requirements: what the client must be able to edit without a developer.
• Integrations, each named: payment, CRM, booking, analytics.
• Performance target, tested on mobile before sign-off.
• Browser and device support.
• Who provides content, and by when.

That last line causes more delay than every technical problem put together.

Who owns the code?

You, and through you, the client. In writing, with the repository in your account from the first commit rather than transferred at the end.

This is not paranoia. A build sitting in a partner's private repository is a build you cannot continue if the relationship ends badly, and the moment you need it is exactly the moment it is hardest to get.

What happens after launch?

Agree three things: how long bugs are fixed free, what counts as a bug rather than a change, and what response time you can promise your client.

A bug is the site not doing what the scope said. A change is the client wanting something different. Projects sour when that line is left undefined and every request becomes a negotiation.

How do you keep the partner invisible?

Four small things cover most of it: no partner credit in the footer, no partner analytics or tag manager accounts, staging on a neutral domain rather than theirs, and commit emails that do not advertise who wrote the code.

Most leaks are mundane. A "built by" line nobody thought to remove, or a staging link in a client email.

How should the build be reviewed?

On a staging URL you can open at any time, with a demo at the end of each week. Not screenshots, not a percentage complete - the actual site, on a real device.

Review in this order, because fixing them in reverse is expensive: structure and content first, then design implementation, then interaction and animation, then performance, then browser and device checks. Studios that leave performance to the end discover that the page weight is baked into choices made in week two.

Who tests it, and against what?

Agree a test list before build starts and keep it short enough that someone will actually use it: every form submits and the email arrives, every link resolves, the site works on a mid-range Android phone, the CMS can edit what the client was promised, analytics and conversion tracking fire, 404s are handled, and redirects from the old URLs are in place.

That last point is the one that costs real money when it is missed. A redesign that changes URLs without redirects throws away whatever search visibility the old site had, and the client sees the traffic drop within a fortnight - at which point it is your problem, not the partner's.

What should you price for yourself?

Your time, which this model tends to hide. Briefing, design feedback, client approvals, content chasing, testing and launch coordination are all yours even when the build is not.

A fair rule is to treat the partner cost as perhaps sixty to seventy per cent of what the project costs you to deliver, with the rest being your own hours. Agencies that quote the partner cost plus a thin margin end up working for nothing on exactly the projects that go slightly wrong.

Is offshore development a risk?

It is a risk the same way any supplier is. What reduces it is not geography but process: a named team, weekly demos of working software, your own repository, and a time zone with enough overlap for a real conversation.

We are an offshore partner ourselves, so weigh that accordingly - the point stands either way. If the arrangement has no demos and no repository access, distance is not your problem; visibility is.

Our terms are on the white label page, and what the build itself includes is on the web development page.