How to brief a white label development partner

The partner needs to know what you sold, what you already have, and what “shipped” means. Taste notes help. They do not replace a page list. If two account people would describe different products, the brief is not done. Finish the argument internally, then write.

For the model definition, see white label development explained. For why you are buying capacity at all, see why agencies outsource web development. Stay here for the artifact: a brief a studio can quote against without a week of discovery you already promised was included.

The day we stopped sending ‘the Figma is the spec,’ our partner quotes got shorter and our client reviews got calmer.

Slack is for exceptions: a delayed asset, a hosting outage, a yes/no on a third-party limitation. The brief is for everything you would be angry to rediscover in week five. If it changes the quote, it belongs in the document, then in a logged change.

When agencies complain that partners “need too much documentation,” they usually mean they wanted production to start while sales was still inventing the product. That is not a documentation tax. That is an unfinished sale. Common white label mistakes start here more often than in the code.

Fill the development partner brief template even on a small overflow site. Short projects fail the same way large ones do: missing access, implied pages, and a client who thought SEO was included. A short brief is still a complete brief.

If you do not know the stack yet, say so and sell discovery—or pick a default you already package. How agencies sell development services is the commercial half of this. The brief cannot invent a CMS the proposal never named.

A marketing site brief that says “see Figma” still needs: component behavior, breakpoints you care about, which frames are source of truth, and what happens with real content lengths. Designers know the happy path. Developers meet the CMS field that is empty and the headline that wraps to four lines.

States the file usually forgets

Empty lists, error on submit, logged-out vs logged-in, hover and focus, loading, and the page with one blog post. If those are not in the file, write the rule in the brief: “Use the design system empty pattern; do not invent illustration.” That sentence saves a review round.

Also name file hygiene: pages labeled, components not detached into chaos, exportable assets, licensed fonts. A white label development partner can build from a messy file. They will bill the archaeology, or they will guess. Guessing shows up as “this doesn’t match our brand” in the client review you have to sit in.

The brief should say whether copy is final, draft, or placeholder, and who enters it. “Client will send copy” is not a date. “Client copy due 3 Oct or we launch with approved placeholders” is a plan. Partners cannot type their way around a missing privacy policy if you sold a legal-complete launch.

Access is where quiet projects die. Hosting, domain registrar, CMS, analytics, payment, newsletter, DAM, and app stores. Name the owner. If the client holds DNS and is slow, the brief should say the launch date moves with DNS, not with wishful thinking.

1. 01

   List every system the build will touch

   Include ‘nice to have’ tools the AM mentioned in the sale. If it is not listed, it is not in the estimate.

2. 02

   Create agency-owned logins where you can

   Do not use a partner personal Gmail. Do not use the founder’s Spotify-adjacent password manager screenshot.

3. 03

   Grant the partner the least privilege that still works

   Staging deploy, not production god-mode, unless production is the job.

4. 04

   Write what happens if access is late

   The calendar moves, or that integration slips to a phase two. Pick one in the brief.

Named vendor plus named behavior is briefable. “Connect to their CRM” is a science project. Ask: create/update which objects, on which events, who owns the account, sandbox vs production, and what happens when the API fails. If nobody knows, it is discovery, not a line in a fixed fee.

Payments, booking, membership, and HubSpot-class tools are where agencies lose months. Put the happy path in the brief and explicitly park the edge cases. A partner who nods at an unnamed integration is not being easy. They are deferring the fight until staging, when the client is watching.

Third-party risk is your risk

If the client’s Salesforce admin is on leave, that is a project risk, not a partner delay. Write it down. Clients respect constraints they saw before they paid. They punish constraints that appear as excuses.

Done is not “looks good.” Done is a list the AM and the partner can both tick. Example: listed templates built to the Figma frames named in the brief; forms deliver to X; CMS editors can create a case study without a developer; Lighthouse or Core Web Vitals targets only if you sold them; browsers you actually test.

Include out of scope in the same document. Native apps, multilingual, membership, custom illustration, and SEO retainers are classic implied extras. If they are not in the client SOW, they should not be in the partner brief as a wink.

Your agency QA pass should use the same list. How to QA white-label work before the client sees it is the gate. The brief is the contract that gate reads.

Write how many revision rounds, what a round is (batched comments vs drip), and what happens after. “Unlimited until happy” is how you donate the partner’s month and your margin. A round is a consolidated list against the approved design, not a new sitemap.

Also write who may instruct the partner. One owner. If a designer pings a developer at midnight, that is not agility. That is a second brief. Put the rule in the document so you can enforce it without a personality conflict.

A first project is also a test of the partnership. Do not simplify the brief to be “nice.” You need to know whether they can work the way you work. Use the same development partner brief template. If they cannot handle it, you learned that on a bounded site instead of a flagship.

Overflow work still needs a complete brief. Speed is not an excuse for a screenshot of Slack. If the internal team is drowning, the AM still spends ninety minutes on intake. That ninety minutes is cheaper than a rebuild. How to vet a white label development partner tells you who is worth briefing; this page tells you what to send them.

The greatest hits: design approved by the client except it was not; two competing Figma files; “mobile later”; SEO as a feeling; analytics “like the old site” with no property access; a launch date that assumes content exists; a partner email CC’d on the client thread so they can “just ask.”

Each of those is recoverable if you catch it in the brief. Each is expensive if you catch it on staging with the client on the call. Brand leaks and client comms are their own articles. The briefing failure is pretending those policies are obvious. Write whether the partner is invisible, which domains they may appear on, and who talks to the client.

The brief that is actually a wish list

If every page is “nice to have if we have time,” you have not prioritized. Partners will build the first items in the file. Clients will review the last item they remember from the pitch. Rank the inventory. Cut below the line in writing.

Retainers still need a brief per increment: this month’s tickets, this sprint’s pages, this campaign’s landing templates. A standing partner without a standing intake becomes a chatroom. Chat rooms do not have acceptance criteria.

Keep a living stack doc (CMS, hosting, conventions) and a short per-job brief. The living doc stops you from re-explaining the design system. The per-job brief stops you from assuming last month’s campaign rules apply. Our process uses that split so agencies are not writing a novel every Monday.

Kickoff is for confirming the brief, not performing it. If you spend the hour restating the sitemap, the document was not read or was not written. Send it 48 hours ahead. Ask for written questions. Use the live hour for risks: content dates, third parties, brand rules.

Then stop talking and let production start. Additional “quick thoughts” belong in a change log. If you want a partner who already works from this kind of intake, book a partnership discovery call and bring a real brief—even a draft from the template. The useful conversation is operational, not theatrical.

If kickoff still turns into a redesign of the sitemap, stop the meeting and update the document before anyone opens a ticket. Building during an unfinished argument is how white label gets a bad name. The partner is not slow. You are still selling.

Keep a copy of the signed brief next to the client SOW. When a week-four request shows up, you will need both. The SOW is what you sold. The brief is what production was allowed to start. If they disagree, you have found the leak before the invoice does.