All guides

What a white-label development agreement should cover

The conditions worth agreeing before an external developer starts delivering under an agency brand.

2 min · Updated 2026-09-05

By Armando Bueno Ben

White-label is not just removing a logo. The agreement should protect the commercial relationship, client assets, delivery process and the technical partner's exit.

01

Confidentiality and commercial relationship

  • NDA from the moment sensitive information is shared.
  • No contact or client solicitation outside the agreed frame.
  • Meeting participation only when the agency requests it.
  • No publishing brands, screenshots or outcomes without explicit permission.

02

Ownership and technical control

The agreement should state where repositories, domains, deployment accounts and documentation live. Delivery should not depend on a personal account the agency cannot access.

  • Ownership of code and deliverables.
  • Agency access to repository, CI and staging.
  • Secure, revocable credential management.
  • Inventory of third-party services and recurring costs.

03

Scope, acceptance and change

A fixed price only makes sense when there is a verifiable outcome. If priorities change often, a retainer or support frame with visible capacity and limits is safer.

  • Deliverables and milestones.
  • Acceptance criteria.
  • Person responsible for validation.
  • How changes are approved and affect timing or budget.

04

Support, handoff and exit

Closure should define included post-launch support, remaining documentation, access revocation and what another person needs to continue.

A clean exit protects both agency and developer by preventing indefinite expectations and out-of-frame emergencies.

05

Example operating annex for a delivery

This example organises working decisions; it does not replace contract terms. For a campaign website, the annex can identify included pages, the reference design and where each form sends data. It also records who supplies copy, consent requirements, analytics accounts and CRM access.

A useful acceptance criterion would be: a valid submission creates one request in the agreed environment and displays confirmation; an error allows retrying without duplicating the request. Add the mobile, keyboard and publication checks included in scope. Acceptance comes from an identified agency owner.

06

When the client changes the request

Adding another CRM, a language or a screen after scope approval requires recording the request, checking dependencies and agreeing its impact before implementation. A visual correction within the approved design and a new feature should be evaluated separately.

  • Keep the approved scope version.
  • Separate defects in the delivery from new requests.
  • Close with code, access, documentation and agreed pending work.

Useful next step

See agency support

A clear frame reduces risk before estimating.

Download the operating brief or share the delivery so these rules can be adapted to the project.

Open the working framework