How to Write a Website Brief That Can Produce a Fixed Quote

A useful website brief does not need to specify frameworks, databases or implementation details. It needs to explain the business context, intended audience, required user journeys, content responsibilities, integrations and boundaries of the first release. A fixed quote becomes realistic when the developer can tell what is included, what is excluded and which decisions remain open.

The brief is not a technical solution. It is a shared definition of the problem and the expected delivery.

Open with the business context

Begin with a short description of the company and why the project exists.

Cover five points:

• what the business offers;
• who buys or uses it;
• which markets the website must serve;
• what is wrong with the current situation;
• why the work matters now.

“Build us a modern website” gives no basis for deciding what the site should contain.

A more actionable version would be: “We are consolidating three overlapping B2B services under one offer. Prospects struggle to identify the right starting point, and our team receives enquiries without enough information to qualify them.”

That statement does not prescribe a design. It identifies a problem the design, content and enquiry journey must address.

If there is a real deadline—such as a product launch, market entry, event or retirement of an existing platform—state it. “As soon as possible” is not a planning constraint unless the reason and immovable date are known.

Define one primary outcome

A website can support several business activities, but the brief should name its primary job.

That job might be to:

• generate suitable enquiries;
• explain a complex service;
• support sales conversations;
• establish the company in a new market;
• enable bookings;
• publish resources;
• present work or products;
• reduce dependence on a developer for routine updates.

Then specify the visitor action that represents progress. Should someone request a consultation, select a service, apply, download a document or contact a regional team?

Vague: “The website needs to convert better.”

Actionable: “A visitor representing an SME should be able to identify the relevant service, understand the engagement model and submit an enquiry containing the project type, desired timing and a short description.”

The second version defines a journey that can be designed and scoped. It does not promise a conversion result that the website alone cannot guarantee.

Describe audiences by decision context

Avoid fictional personas filled with unsupported demographic detail. Describe real audience groups and how they approach the decision.

For each group, explain:

1. what brings them to the website;
2. what they already know;
3. which questions or objections they have;
4. what evidence they need;
5. whether they decide alone or with colleagues.

An EU startup may need to satisfy a founder, product lead and technical reviewer. A Slovenian owner-managed company may have one decision-maker but require localized language and a more direct route to contact.

If several countries are in scope, list the required languages and clarify whether content will be translated or independently localized. Also state who approves each version. A multilingual website is not only a language switch; it introduces additional content, navigation and publishing responsibilities.

List page types, not only page names

A sitemap is helpful, but the number of pages does not reveal the full workload.

Separate unique page types from repeated entries. For example:

• homepage;
• service overview;
• individual service;
• case study;
• resource article;
• team profile;
• location;
• contact.

Twenty articles using one template differ from five pages with five distinct structures.

For every page type, note its purpose, required content and intended call to action. If the sitemap is not final, identify which pages are confirmed and which are provisional.

This also helps prevent a familiar ambiguity: one side expects a flexible content system with several reusable templates, while the other believes the scope covers a small set of static pages.

Assign ownership of every content input

Content delays and scope disputes often begin with the phrase “content will be provided”.

The brief should state who is responsible for:

• writing and editing copy;
• supplying photography and brand assets;
• preparing translations;
• checking technical or regulatory wording;
• approving each language;
• entering content into the new website;
• migrating material from the existing site.

Vague: “We will provide the text and images.”

Actionable: “Our marketing lead will provide approved English copy and selected brand photography before development begins. A local partner will prepare German copy after the English structure is approved. Existing articles must be migrated; outdated campaign pages can be removed.”

This makes ownership and dependencies visible. It also allows the quote to distinguish content design, production, entry and migration rather than treating them as one undefined task.

Explain functionality as a workflow

Feature labels are rarely precise enough for a fixed quote.

“Contact form”, “booking”, “CRM integration” and “member area” can each describe many levels of complexity. For every function, explain:

• what the user does;
• which information they provide or receive;
• where the data goes;
• who acts on it;
• what confirmation is required;
• what the internal team must manage afterwards.

Vague: “We need a form connected to our CRM.”

Actionable: “The form should collect name, work email, company, market, project type and message. On submission, it should notify our sales inbox and create a lead in our existing CRM. We can provide access to the platform and its API documentation.”

For third-party systems, name the product, account owner and available access. If the tool has not been selected, mark the integration as undecided. Do not describe an unknown system as though it were a confirmed implementation task.

Sort scope into three priorities

Use three explicit groups.

Required for launch

Items without which the first release cannot perform its primary job. This includes essential content, languages, forms and integrations tied to the main user journey.

Valuable later

Useful additions that do not prevent a coherent launch. Examples may include another language, advanced filtering, secondary integrations or additional automation.

Undecided

Ideas that have not yet been validated or lack clear rules, ownership or technology.

This classification is particularly useful for startups, where future product plans can easily enter a website brief as immediate requirements. A fixed quote should cover a defined release, not every possible direction the business might take.

Record practical constraints and assumptions

Include the people, systems and dependencies that affect delivery:

• the final decision-maker;
• contributors and reviewers;
• existing domain and hosting;
• brand guidelines;
• analytics and marketing tools;
• content migration requirements;
• internal security or procurement checks;
• required access;
• the feedback and approval process.

Then state the assumptions on which the quote can rely.

For example:

• the first release contains two languages;
• approved copy is supplied by the client;
• one enquiry workflow is included;
• user accounts and payments are excluded;
• migration covers the listed content types;
• integrations not named in the brief require separate assessment.

Assumptions are not hidden exclusions. They are the reference point that makes a fixed scope understandable. If an assumption changes, both sides can identify the effect before additional work begins.

For more detail on those variables, read What Actually Determines the Cost of a Custom Website?.

Use a final brief checklist

Before sending the brief, confirm that it answers:

• What business problem should the website address?
• Who are the priority audiences?
• What must visitors understand and do?
• Which page types are required?
• Which languages and markets are included?
• Who owns copy, translation and visual assets?
• How does each important function work?
• Which external systems are involved?
• What is required now, later or still undecided?
• Which assumptions define the quote?
• Who approves scope and content?

If the team cannot yet agree on the underlying problem, read When a Website Redesign Won't Fix the Business Problem before turning the request into a build specification.

For custom website design and development, you communicate directly with the person handling the design and development. If you have a draft brief, send it through the contact section; I reply within 24 hours.

← Back to the blog