How to brief a development partner for an agency project

A useful web development brief explains the job, the decisions already made and the questions still open. You do not need to choose every library or write a technical specification before asking for help.

For an agency project, it also needs to explain who does what: your team, your client and the developer. Start with the essentials below, then use the template to put them in one place.

Start with the client problem

Describe what needs to change and who will use the result. A page list helps, but it is not the whole brief.

For example, “build an enquiry form” leaves a lot open. “Let visitors send a service enquiry into the client’s CRM, with a clear confirmation and a way to spot failed submissions” explains the intended outcome.

Include the current website or system, if there is one, and what is getting in the way. Separate the first release from ideas that can wait.

Show what is ready to build

Explain whether the work starts from approved designs, a prototype, an existing codebase or an early outline.

If you are supplying designs, include the relevant screens and explain which are approved. Note what should happen on smaller screens, how forms behave and whether loading, empty or error states have been considered. It is fine to have gaps; identify who will resolve them.

List who supplies the copy, images and other assets. If the client still needs to approve something, make that dependency visible rather than treating it as ready.

Describe functionality and connections

Explain what people should be able to do. “An editor can update service descriptions without changing the layout” is more useful than “easy to manage”.

For connected tools, name the systems and describe the information that should move. Include the direction, timing and which system takes priority if records differ. If you do not know whether a tool supports the connection, put that down as an open question.

For website enquiry flows, the website-to-CRM integration checklist covers field mapping, duplicate handling and failed deliveries.

Mention any fixed platform, hosting or data-handling requirements. If these are undecided, say so rather than choosing tools just to fill the brief.

Keep access credentials and real customer records out of the brief. Use fictional data to illustrate a form, dashboard or workflow. Access can be arranged separately when needed.

Make the agency responsibilities clear

Agree who answers questions, collects feedback and approves the finished work. If the client needs to review through your agency, say so. If you want the developer involved directly, explain what that involvement would cover.

Also identify who controls the domain, hosting, source repository and third-party accounts. State any confidentiality or client-contact requirements before the work is scoped; do not assume everyone works the same way.

Reviews can happen in writing. A shared preview, consolidated feedback and a clear decision-maker make the review process easier to follow.

Explain the deadline, budget and acceptance

Give the target date and the reason behind it. A campaign launch, client commitment and preferred completion date are different constraints. Note when designs, content and access will be available, and who needs time to review.

Include a budget range or ceiling if you have one. If it is undecided, say that and identify the essential first release. Do not ask the developer to infer the budget from a competitor’s website.

Describe how you will judge the result. Replace “the integration works” with observable behaviour: a valid enquiry creates the agreed record, missing fields are handled, and failures are visible to the person responsible.

Specify the agreed devices, browsers and accessibility requirements. Confirm what source files, account access and setup notes you expect at handover. Keep ongoing support separate from the initial build unless it is explicitly included.

Copy this development brief template

Use this as a starting point. “Undecided” is a useful answer when you need advice.

PROJECT
Agency and project:
What the client needs to achieve:
Who will use the result:
Existing website or system:

SCOPE
Essential first-release pages or features:
Out of scope or possible later work:
Designs, code and assets already available:
Outstanding decisions and who owns them:

FUNCTIONALITY AND DATA
What users need to be able to do:
Tools or systems to connect:
What data should move, where and when:
Important permissions, errors or edge cases:
Fixed platform, hosting or data-handling requirements:

RESPONSIBILITIES
Who supplies designs, copy and assets:
Agency contact and final decision-maker:
Client review and communication arrangements:
Who owns hosting, accounts and source code:

DELIVERY
Target date and why it matters:
When content, access and reviews will be available:
Budget range or current budget position:
What must be checked before acceptance:
Source files, documentation and access to hand over:
Ongoing support required, if any:

OPEN QUESTIONS
What you need advice on:

Do not include passwords, API keys or confidential client data when sharing the brief. A sanitised outline is enough for an initial conversation.

Worked example: an agency website and enquiry flow

This is a fictional example to show the level of detail, not a client project or a quotation.

Project and goal A small design agency is rebuilding a service business’s website. Visitors should be able to read about the services and send an enquiry that reaches the client’s existing CRM without manual re-entry.

First release Build the supplied website designs, an enquiry form and the agreed CRM connection. A customer portal and newsletter automation are outside this release.

What is ready The agency has approved desktop designs and draft copy. Mobile navigation, form errors and the confirmation state still need decisions. The agency owns those decisions and will confirm them before the relevant build work starts.

Data and behaviour The form asks for a name, email address, selected service and message. A valid submission should create the agreed enquiry record in the CRM. Whether to create or update a contact with an existing email address is still to be agreed. A failed CRM request must not be shown to the visitor as a successfully delivered enquiry.

Responsibilities The agency supplies final designs and copy, gathers client feedback and gives written approval. The client controls the CRM account and domain. Hosting ownership, access permissions and the repository handover need to be confirmed in the proposal.

Timing and budget The client wants the website ready before a campaign, but the campaign date and review window are not confirmed. The budget is also undecided. The agency wants a scoped proposal for the first release, with optional work separated rather than assumed.

Acceptance and handover Check the agreed mobile and desktop layouts, required-field handling, successful enquiry creation, duplicate-contact behaviour and CRM failure handling. Hand over the source, setup instructions and a note explaining who handles future failures. Ongoing monitoring is a separate decision.

The open questions are part of the brief. They give the developer something specific to investigate instead of hiding assumptions in the estimate.

Compare proposals against the same brief

Check that each proposal covers the same work, responsibilities, testing and handover. If one excludes content migration, error handling or setup, that changes what its headline price means.

Ask how scope changes are agreed and who owns unresolved decisions. A useful proposal should make the boundaries clearer, not simply repeat your page list.

Have a project ready to discuss?

Odd Little Bits builds websites, web apps and integrations for small agencies that need development help without hiring in-house.

Send your outline, what is ready and where you need help. You do not need every answer before getting in touch.