A website brief should include your business goals, target audiences, key customer journeys, proposed pages, content responsibilities, essential functionality, integrations, budget and launch constraints. It should also explain who will approve the work and manage the site afterwards. Before asking for quotes, separate confirmed requirements from ideas and unanswered questions, so developers can price the same job rather than make different assumptions.

You do not need to design the website or write a technical specification yourself. Your job is to explain the business, the outcome and the boundaries. A short document with supporting examples is a sensible starting point for a straightforward new business website. More complicated selling, booking or account journeys need more detail.

1. Explain the business and the website’s main job

Start with what you sell, who buys it and how the business operates. Include your service area, whether customers buy directly or speak to someone first, and any important distinction between your offerings. A developer should not have to reconstruct the business from social media posts.

Then state the website’s primary job. “Generate qualified enquiries for commercial maintenance contracts” gives a clearer direction than “create a modern online presence”. Secondary goals might include answering common questions, attracting applicants or helping existing customers find documents. Rank them rather than treating everything as equally important.

Explain how you intend to judge success. For a new business without baseline data, describe the customer action you want to measure rather than inventing a growth target. Ask for measurement setup to be included in the scope if you need it.

2. Describe audiences through the tasks they need to complete

“Small businesses” is a market category, not enough information to plan a useful website. Explain who within those businesses visits, what they need to know and what might prevent them from taking the next step.

For example, a hypothetical training provider might serve an employer booking places for several staff and an individual checking whether a qualification suits them. Those visitors need different information, even if both eventually use the same enquiry form.

Write the main journeys as plain sequences: find the relevant service, check suitability, review evidence, submit an enquiry. Include what happens afterwards. Does a team member call back, does the visitor choose an appointment, or should the website send a document? The journey does not end at the submit button.

3. List pages, content types and who supplies them

Provide a provisional page list, but distinguish individual pages from reusable layouts. Twelve service pages using one layout represent different work from twelve individually designed pages. Identify repeatable content such as products, staff profiles, case studies, locations or events, and give approximate quantities.

For each content group, record whether material exists, needs editing or must be created. “We will supply the content” is incomplete if nobody has allowed time to write it, select images and enter it into the site.

  • Copy: name the writer and approver, and say whether copywriting or editing should be quoted.
  • Assets: list available logos, brand guidelines, photography, video and downloads, noting any permission questions.
  • Content entry: specify who uploads pages, products and documents, including any launch allowance you want priced.

If replacing a website, identify content to retain, rewrite or remove. Flag important existing addresses so the developer can assess migration and redirects, which send visitors from old addresses to their replacements. Do not assume “new website” includes moving everything.

4. Describe functionality as behaviour, not feature labels

Labels such as “booking system”, “search” and “customer area” leave substantial room for interpretation. Explain who uses each feature, what information they provide, which rules apply and what result they should receive.

For example, a hypothetical appointment brief could say: visitors choose a service and available time, pay a deposit, receive confirmation and request cancellation through a link. Staff need to block dates and see upcoming appointments. That description exposes questions about availability, payment and cancellation that “online booking” leaves unanswered.

For an online shop, explain the catalogue, product options, delivery regions, collection arrangements and any unusual pricing rules. For forms, list the fields, recipients, attachments and expected response. Mark each requirement as essential for launch, desirable or later. Ask suppliers to price optional work separately rather than hiding it inside the core build.

5. Identify integrations and editing needs

List any software the website must exchange information with, such as your customer relationship management system, email marketing service, stock system or booking platform. State the exact service and account plan where known, what data should move and in which direction. Include links to documentation in your brief if you have them.

“Connect enquiries to our sales system” still needs clarification: should it create a contact, create an opportunity, assign an owner or all three? Identify the person who can answer these questions. If compatibility is unknown, request investigation rather than treating the connection as confirmed.

Describe internal editing tasks too. Who changes prices, publishes articles or adds services? Do changes need approval? State any platform constraint and its reason, but leave the choice open if you have none. The WordPress or Shopify comparison offers a useful next step when you need to weigh a content-led site against a shop.

6. Give design direction and quality expectations

Supply a few reference websites with specific comments: clear service navigation, readable product details or a helpful comparison layout. Explain what does not suit your business too. References should communicate priorities, not ask the developer to copy another organisation’s design.

Say whether you already have a designer or need design included. Ask the proposal to explain how accessibility, mobile use, performance and search foundations will be addressed and checked. Flag known accessibility needs or contractual standards, and ask for any specialist assessment to be scoped explicitly rather than relying on a vague “fully compliant” promise.

Identify forms, tracking tools and sensitive information you expect to handle. Assign responsibility for privacy wording and any specialist advice. The brief should expose these decisions, not attempt to settle legal questions through a generic requirement.

7. Set a budget, timetable and decision process

Give an available budget range and clarify whether it covers design, development, content, photography and launch. Separate the initial project budget from what you can spend on running the site. Without those boundaries, suppliers may propose quite different levels of work.

State the desired launch date, why it matters and whether it is fixed. Include dependencies such as brand approval, product photography or a third-party account. Name one person to consolidate feedback and identify who has final approval. Record when those people can review work.

Leave room for a developer to challenge assumptions before quoting. FullyCoded starts projects with a structured conversation about the business, its users and the outcome needed. Its development process is a useful reference for understanding how an initial brief progresses towards agreed scope.

8. Define launch, handover and ongoing ownership

Ask for training, documentation and account handover to be identified in the quote. Specify that the business needs appropriate control of its domain, hosting, website administration and connected accounts. Share an access inventory, not passwords, in the initial brief.

Request a clear split between fixing defects in the agreed build, ongoing maintenance and future improvements. Ask who handles updates, backups, recovery and urgent faults, and what support costs separately. Include practical acceptance checks, such as completing an enquiry, receiving its notification and editing a service page without developer help.

Send one brief and ask for comparable responses

Send the same dated brief to each shortlisted supplier. Ask each to identify included work, exclusions, assumptions, client responsibilities, recurring charges and unresolved questions. Request clarity on whether figures are fixed or estimated and whether VAT is included.

If an answer changes the requirements, update the brief for everyone. Where a major unknown prevents reliable pricing, ask for a defined discovery stage first. Before comparing totals, check that every proposal covers the same essential customer journey, content workload and launch responsibilities.