A website handoff is ready when a production partner can identify the approved scope, locate the current inputs, and tell who has authority to answer each open question. A folder full of logos and page copy does not provide that operating context.
For an agency using a white-label partner, the brief also has to preserve the client relationship. The agency remains the source of approved client direction unless the engagement says otherwise. The production team needs one documented route for questions, reviews, and changes.
Freeze the baseline before production starts
Start with the version that everyone has approved. Record the project objective, audience, required pages, expected functions, target platform, delivery boundary, and named reviewers. If the site must support lead capture, gated content, account access, ecommerce, or another workflow, define the expected user action and what counts as completion.
The handoff should distinguish requirements from references. A competitor page may illustrate navigation behavior, but it does not automatically authorize copying its structure or content. A mood board can guide visual direction, but it does not replace an approved component list.
Record who owns each decision
A short responsibility table prevents quiet assumptions.
| Decision | Agency or client input | Production partner output |
|---|---|---|
| Audience and offer | Approved business brief | Page structure that follows the brief |
| Content | Final copy or named copy owner | Implemented content and flagged gaps |
| Brand | Approved assets and usage rules | Consistent application in the build |
| Functions | Required behavior and acceptance tests | Working implementation for review |
| Launch | Domain, hosting, analytics, and approval authority | Agreed deployment package and release notes |
If responsibility is shared, document the boundary. For example, the agency may supply final form fields while the production partner implements validation and presentation. The handoff should identify who owns the receiving system and who tests the complete submission flow.
Package content and assets for use
Organize inputs by page or component rather than by the date someone emailed them. A useful package normally identifies:
- the approved sitemap and page names;
- final copy, draft copy, and missing copy as separate states;
- logos, icons, photographs, illustrations, and their usage rights;
- image crops or focal points when a single asset must serve several layouts;
- form fields, confirmation behavior, recipient ownership, and privacy copy;
- analytics events or tag requirements that the agency has approved; and
- the source of legal, policy, accessibility, or regulated statements.
Use stable filenames. home-hero-approved.jpg is easier to review than final-new-2.jpg. Do not place passwords, secret keys, private client data, or live credentials inside the general project folder.
Describe integrations as interfaces
An integration handoff needs more than the name of a platform. State the environment, authentication method, permitted test data, endpoints or actions in scope, error behavior, rate or usage constraints supplied by the platform owner, and the person who can approve access.
When an HTTP API has an OpenAPI description, provide the current document and identify any behavior that lives outside it. The OpenAPI Specification defines a standard interface description for HTTP APIs, which can give production and review teams a shared reference. The document still needs project context: which operations matter, which environment is safe for testing, and which party owns changes.
For work that needs an implementation partner, Brownsofts provides white-label web apps with API integrations under an agency-led brief. The commercial page describes that service; this handoff article focuses on the inputs an agency should prepare.
Protect existing URLs during a rebuild
A replacement site should include an inventory of current public URLs. Mark each URL as retained, redirected, consolidated, or intentionally removed. Where a URL changes, identify the exact destination rather than sending every old page to the homepage.
Google's site-move documentation recommends mapping old URLs to new ones, using server-side permanent redirects, updating canonical links, and updating internal links. Add those items to the launch plan before development ends. The agency should also identify which analytics, search, or backlink information it used when deciding what to retain.
Define acceptance in observable terms
Replace broad requests such as "make it polished" with checks a reviewer can perform. Examples include:
- Every approved navigation item reaches the named destination.
- Each form displays its required fields and documented confirmation state.
- The agreed layouts remain usable at the review widths in the brief.
- Editors can update the content types assigned to them.
- Redirects resolve to the approved final URLs without a chain.
- The handoff package includes the agreed source files, account ownership notes, and unresolved items.
The list should reflect the actual project. A brochure site, a campaign experience, and an authenticated application need different acceptance checks.
Hand off an issue log, not hidden uncertainty
Unresolved items do not disappear when production starts. Keep a short log with the question, owner, impact, due date, and current decision. Mark a blocked item clearly instead of allowing the production team to invent a substitute.
At that point, the partner can estimate the remaining work, build from approved material, and send focused questions through the agency.