Wilde Digital
Guide

What to put in a white-label website brief

Overflow projects often go wrong at the brief rather than the build. This is the checklist a developer needs in order to quote a fixed price and build without guessing — with a template you can copy.

White-label development scopeAsk a specific question

Last updated . Written by Zack Wilde. Prices quoted are Wilde Digital's own published starting rates as of September 12, 2026; they are not market averages.

The short answer

A good white-label brief answers four questions before anyone writes code: what exactly is being built, what “done” means, who decides, and what the developer may not do. Everything in the template below is one of those four. A brief that answers them gets an accurate quote; a brief that does not gets either a padded quote or a dispute later.

The twelve items

  1. Page and template inventory. Every page type, with how many instances of each. “About ten pages” cannot be priced.
  2. Approved design files, including mobile layouts. If mobile was not designed, say so, so the developer can propose and you can approve.
  3. Final copy and licensed assets. Or a clear statement of which are still coming and when.
  4. Platform and hosting. CMS or framework, where it will be hosted, and who owns those accounts.
  5. Integrations. Forms and where submissions go, analytics, payment, booking, CRM. Each one is scope.
  6. Interactions and states. Menus, sliders, filters, form errors, empty states. Designs usually show the happy path only.
  7. Browsers and devices to support. A short, explicit list.
  8. Content editing needs. What the client must be able to change themselves after launch.
  9. URL changes and redirects, if this replaces an existing site. Old URLs need a destination.
  10. Acceptance conditions. The checks that mean a page is finished.
  11. Feedback owner and approval process. One contact who consolidates client feedback and approves changes.
  12. Confidentiality and contact rules. No client contact, no credit, no portfolio use unless agreed.

How the brief turns into a build

1. Brief reviewed,gaps listed2. Scope andprice agreed3. One representativepage built4. Agency reviewsthat page5. Remaining pagesfollow the pattern6. Checks run,handover delivered
The brief is reviewed first, one representative page is approved, and only then does the rest of the build follow it.

The representative page is where most gaps in a brief surface. Approving it before the rest of the build saves rework across every page that follows.

Copy this template

PROJECT:            [internal name — not the client's]
DEADLINE:           [date the agency needs the handover]
PLATFORM / HOSTING: [e.g. WordPress on client host; who owns accounts]

PAGES / TEMPLATES:  [type — number of instances], [type — number], ...
DESIGN FILES:       [link] — mobile designed? [yes/no]
COPY + ASSETS:      [final / pending by date] — licences confirmed? [yes/no]

INTEGRATIONS:       [form → destination], [analytics], [other]
INTERACTIONS:       [menus, filters, sliders, error and empty states]
BROWSERS / DEVICES: [list]
CLIENT EDITING:     [what the client must be able to change]
REDIRECTS:          [old URL list attached? yes/no]

DONE MEANS:         [acceptance checks, per page type]
FEEDBACK OWNER:     [one name at the agency]
CONFIDENTIALITY:    no client contact · no credit · no portfolio use

Remove anything that does not apply rather than leaving it blank — a blank field reads as “not decided”.

If parts are still missing

Send the brief anyway, with the gaps marked. A developer who lists what is missing and prices the known parts is more useful than one who quotes a single number for an undefined job. Wilde Digital’s white-label process starts exactly there: the brief is reviewed, the unresolved questions are returned as a short list, and the quote ($6,500–$12,000 USD per scoped build) covers what is actually defined. If you are still choosing a supplier, how to vet a white-label web developer covers the questions to ask first.

Common questions

Do I need a full specification document?

No. The twelve items above are enough for most marketing sites. Long specifications often describe intentions rather than decisions; a short brief with explicit acceptance conditions is easier to quote and to check.

What if the client keeps changing the design?

That is a scope question, not a build question. Agree in the brief what counts as a change and how it is priced, and route every change through the one feedback owner so it is visible before it is built.

Should the brief name the client?

Only if the developer needs it, for example to access the client’s hosting. An internal project name is enough for quoting. Confidentiality terms should cover the client’s identity either way.

Want this applied to your business?

Send the site and the problem. You get an honest read on what is worth doing first, whether or not it is something Wilde Digital sells.

Start an inquiryWhite-label development scope