Agency development brief
What an agency should prepare before handing over development.
An agency guide to preparing a development handoff: client outcome, designs, scope, approvals, dependencies, commercial responsibilities and acceptance.
A good development handoff does not require the agency to become a software consultancy. It requires a clear explanation of the client outcome, the work being commissioned and the decisions that remain with the agency.
The aim is to make responsibility visible. A developer should not have to guess whether a missing screen, an integration or a late client request is part of the agreed engagement.
Describe the client outcome before the technology
Explain what the client is trying to deliver and who will use it. “Implement these designs” may be part of the task, but it does not explain what the application must accomplish.
For example, an illustrative brief might be: “Create a partner portal where approved partners submit requests and the client's staff review them. The agency supplies the interface designs and consolidates client feedback.” This gives the project a user journey and a division of responsibility.
It is an example, not a reference to an existing client engagement.
Define the developer's boundary
State whether the commission covers a complete application, a frontend implementation, a backend component or an integration. Name the parts that will be supplied by the agency or another party.
A partial build needs clear integration points. Who provides the API? Who owns the final deployment? Who tests the combined result? Without those answers, a small component can acquire a much larger implied responsibility.
Provide the design decisions, including states
Supplied designs should identify the intended desktop and mobile behaviour and the important states of a screen. Empty content, validation errors, loading and completion states all need an answer.
Where the agency has not designed a state, mark it as a decision to resolve. That is better than leaving the developer to invent behaviour and discovering later that the client expected something different.
Identify which assets and text are approved, and which are provisional. The development environment should not make a placeholder look like approved customer-facing copy.
Establish the review and communication path
Name one person who consolidates feedback for the agency. Explain whether the developer will attend client meetings, answer questions through the agency or participate only in agreed technical discussions.
Set out who can approve a change. A client idea, an agency preference and a contractual requirement are not automatically the same thing. Keeping a decision record helps everyone understand what has actually entered the scope.
A white-label arrangement also needs practical rules: meeting introductions, access, branding on deliverables and permission to mention the project publicly. These points belong in the agreement rather than in assumptions.
Share dependencies without sharing secrets carelessly
List the relevant systems, documentation, hosting arrangements, repositories and third-party accounts. Explain who owns them and how appropriate access will be provided.
Do not place passwords or API secrets in a general project brief or ordinary enquiry form. Use an agreed secure channel and limit access to what the task needs.
For integrations, include available test accounts, sample payloads without private data and a contact for business-rule questions. An API link alone does not explain what the client expects the connection to achieve.
Make acceptance concrete
Describe what the agency will review at each milestone. A useful acceptance example states an action and a result: a partner submits a request, staff can review it and the partner sees the agreed status.
Agree how issues will be recorded, how feedback is consolidated and how changes outside scope are handled. The purpose is not to make revisions difficult. It is to distinguish completing the promised feature from commissioning a new one.
Define the delivery package
The agreed handover might contain code, deployment notes, configuration information, administration guidance and a list of dependencies. Ownership and licence terms determine what can be transferred or reused; do not infer them from access to a repository alone.
Separate acceptance, an agreed defect-correction period and any future development. A completed project should not quietly turn into unlimited technical availability for the agency or its client.
A useful first message
Give the intended outcome, the part you want developed, the design status, the known integrations, the desired delivery window and any budget parameters. Then name the decision-maker and preferred communication arrangement.
That is enough to begin a focused conversation. The detailed scope can be agreed once the important boundaries are understood.
Explore agency development partnerships or send an agency brief.