Website development brief: a checklist before you request a quote

A useful website brief helps a development team understand the work you need and the decisions that are still open. It also helps you compare proposals that might otherwise include different assumptions.

You do not need to choose every technology before speaking to a developer. Start with your business goal, the people using the site and the tasks they need to complete. Use the checklist below for a new website, an ecommerce project or a web application.

1. Define the goal and the first release

Write one sentence describing what the project should help your business do. Then identify the main users and their most important task. For a services website, that might be finding the right service and sending an enquiry. For a customer portal, it could be signing in and viewing an invoice.

Separate what must be ready at launch from what can follow. Record why any launch date matters and which dependencies could affect it.

2. List pages, journeys and content

A page list is useful for a marketing site. An application also needs user journeys: what someone enters, what happens next and which result they should see.

Identify who supplies text, images, products and other content. For a rebuild, note what should be retained, rewritten or removed. Include the person who approves each type of material.

3. Describe integrations and data changes

List the services the project must connect to, such as a CRM, payment provider, booking system or inventory platform. For each one, explain what information moves and which system is responsible for it.

If you are migrating content or data, record its source, approximate amount and anything that must be preserved. Use fictional examples when sharing a brief. Keep passwords, customer records and access tokens out of the document.

4. Agree how the work will be accepted

Replace vague requests such as “a better enquiry form” with a behaviour you can check. For example: a visitor can select a service, enter the required details, submit the form and see a clear confirmation only after the submission succeeds.

Include important failure cases. What should happen if a required field is empty or a connected service is unavailable? Agree the browsers, devices and user journeys that need testing for your audience.

5. Make ownership and ongoing work clear

Identify who provides accounts, approves designs and authorises launch. Ask how source code, documentation and administrative access will be handed over.

Separate project delivery from ongoing work. Hosting, subscriptions, maintenance and additional features may have different costs and responsibilities. Ask for those assumptions to be visible in the proposal.

Copy this project brief

• Project and business goal:
• Primary users:
• Most important user journey:
• New build or existing website/application:
• Existing website URL, if any:
• Required pages or features:
• Features that can wait:
• Integrations and data migration:
• Who supplies content and designs:
• Acceptance criteria and testing needs:
• Target launch window and dependencies:
• Budget range and currency:
• Decision-maker and review process:
• Hosting, maintenance and handover requirements:
• Open questions:

Use “undecided” where you need advice. A visible open question is more useful than an assumption that only becomes clear after work begins.

Compare proposals against the same brief

Check that each proposal covers the same deliverables, exclusions, responsibilities and acceptance criteria. Ask what would trigger a scope change and how it would be agreed. A lower headline estimate may cover less work, while a larger one may include services you do not need.

For an early budget, use our website development cost calculator. For application projects, explore our web application development services. If you already have the brief, tell us what you want to build and which questions you would like to resolve.

Back to the blog