Website development brief template for creative agencies

Brief a developer before you quote your client. A practical website brief template for creative agencies, with responsibilities and a worked CRM example.

“An enquiry form connected to the CRM” sounds clear enough to put in a proposal. It leaves a fair bit open: which system, what happens to the enquiry, and whether the client’s account supports the connection.

When your agency is buying development for a client project, those gaps matter before you agree a price. A useful brief gives the developer enough detail to expose them, then gives you something concrete to check against their quote.

The template below is for briefing an external developer before you quote your client. It covers the website work, who supplies what, and the decisions that still need an answer.

Send enough to start the conversation

You can ask for an initial estimate while the designs are still taking shape. Send the current designs or sitemap, what the site needs to do, the intended launch date and the development budget you have available. Explain which parts your agency will deliver.

Label the unfinished parts. “Desktop designs ready; mobile layouts still being designed by us” gives the developer a useful starting point. Without that note, they may allow for designing the mobile layouts themselves, or assume someone else has already done them.

Ask how much confidence they have in the estimate and what they need before they can confirm scope and price. Keep those qualifications attached when discussing the figure internally.

Copy this website development brief

Download the brief and quote-comparison worksheet (Markdown)

You can open the download in a text editor. It includes space for your answers, a developer response section and an internal worksheet for comparing quotes. No signup is needed.

Use this as a working document. Write “unknown” where you need help, with a person responsible for finding the answer. Remove rows that do not apply.

FieldWhat to put in the brief
Project and purposeAgency, client or agreed project alias, current site, and what visitors need to be able to do on the new site.
First releaseWhat must be ready for launch, plus anything already deferred. State whether the launch date is fixed and why.
Pages and layoutsSitemap, number of distinct layouts, and approximate amount of content. Ten case studies using one layout still need someone to enter and check ten case studies.
DesignLink to the current files. Name who supplies mobile layouts, interactions and missing states, such as form errors. Mark anything still awaiting client approval.
ContentWho supplies copy and images, who enters them, and when they will be ready. Include any content being moved from the existing site.
Client editingWhat the client must be able to change themselves. For example, add a case study using the agreed layout without asking a developer.
Forms and connectionsRequired fields, where submissions go, what happens next, and systems involved. Note who can arrange documentation and suitable test access.
Existing sitePages and files to retain, approximate migration volume, and who supplies and checks the list of old addresses that need redirecting.
Quality checksKnown accessibility requirements, supported browsers and any performance targets. Ask the developer to propose suitable checks where these have not been agreed.
Accounts and launchWho owns the domain, hosting and other services; who can grant access; and who carries out launch. Agree which source files and documentation will be handed over, who will own them, and when. Name who supplies approved privacy and consent requirements.
Review and approvalAgency contact, client approver, feedback route and time allowed for reviews. State whether the developer may speak directly to the client.
Commercial assumptionsDevelopment budget, any required pricing breakdown, and known third-party costs. Ask the developer to identify exclusions and ongoing charges.
After launchWho handles reported faults, hosting and future changes. Ask for the proposed support terms and costs.
Open decisionsEach unanswered question, who will resolve it, and when the answer is needed.

Link to the design version being quoted. If it changes during estimating, tell the developer what changed and ask whether their price still applies.

Use a secure access method for credentials. Passwords and API keys do not belong in this document.

Keep your client price in your agency’s commercial notes

Give the developer the budget available for their work. Keep your client selling price and margin calculations in your internal proposal notes unless you have a reason to share them.

Be explicit about the working relationship too. If all questions must come through your account lead, say so. If a technical call with the client is allowed, agree how the developer will be introduced and what can be discussed.

A supplier brief and a client proposal serve different purposes. Check the contents before forwarding either, particularly wholesale costs and supplier details covered by your confidentiality agreement.

Worked example: the CRM connection

This is a hypothetical agency project.

The client wants a new service website. Your agency is supplying design and copy; the developer is building the site and enquiry form. The client has asked for enquiries to “go into the CRM”.

Part of the briefCompleted example
Required behaviourA valid enquiry creates a lead in the client’s CRM, including the selected service. The visitor sees confirmation once the enquiry has been safely received.
Unanswered questionDoes the client’s current CRM subscription support the required connection, and can they provide test access?
Person responsibleAgency account lead obtains the subscription details and arranges access with the client’s CRM administrator. Developer checks the proposed connection.
Initial estimate assumptionDeveloper prices the website and an email enquiry route. Direct CRM delivery is excluded pending the access check.
Decision needed before the client proposalConfirm the CRM work and its price, or get the client’s agreement to launch with email enquiries and handle CRM delivery separately.

Email delivery is only an acceptable first release if the client agrees to it. If automatic CRM delivery is essential, allow time to investigate it before committing to the build.

Once the connection is understood, agree how it will be checked. For this example, a test enquiry should reach the correct CRM account with the selected service intact. The agreed behaviour should also cover failed delivery, so a visitor is not told an enquiry has been received when it has been lost.

The same approach works for booking tools, payment systems and content migrations: describe the required behaviour, identify the unanswered part, and give someone responsibility for resolving it.

Ask for a quote you can check against the brief

Ask the developer to reference the brief version in their response and explain:

  • What their price includes, including content entry and any design work.
  • What is excluded or depends on an assumption.
  • What they need from your agency and the client, with dates.
  • How reviews, corrections and requests for extra work will be handled.
  • Any recurring charges, payment terms and support terms.
  • How long the quote is valid, whether delivery capacity is confirmed, and what secures the start date.

Read the assumptions against the project you intend to sell. If the developer has allowed for your team to enter all the content, your proposal needs to account for that work. If their schedule depends on approved designs arriving on Monday, check that your client approval schedule makes Monday possible.

Resolve any mismatch before accepting the quote. A change to the brief may need a revised price or delivery date.

Compare responses to the same brief

The download includes a quote-comparison worksheet. Keep it in your agency's internal notes, since it may contain competing supplier prices and terms.

Record each developer's answer against the same brief version, with a reference to the relevant part of their quote. Compare what they include, what your team must supply, the acceptance checks and any ongoing costs. Mark an unanswered item as “not confirmed”.

For example, one quote might include entering all the case studies while another covers only the case-study layout. Put the content-entry work in the worksheet's uncovered-work table, identifying which quote it applies to, with an owner and the effort still needed. If the lower quote excludes content entry, your agency still has that work to account for.

Keep one-off and recurring costs separate. Check currency, VAT treatment and who pays each service charge. Resolve changes with the developer in writing before accepting, including any effect on the start date.

Carry the agreed responsibilities into your client proposal

Use the confirmed scope to write the client-facing proposal. Include what the client must supply, approval dates and the treatment of later requests. Keep internal supplier terms in the appropriate agency documents.

For the CRM example, the proposal should say which enquiry route is included at launch. Leaving “CRM integration” in the client proposal while accepting a developer quote that excludes it leaves your agency with work to arrange and fund.

At Kyln, I work with creative agencies as their development partner. You keep the client relationship and set your client price. If you have a website brief taking shape, get in touch about agency development and I can help work through the open technical questions before you quote.