# Website brief: the checklist to prepare before a quote

> A practical website-brief checklist covering objectives, content, features, responsibilities, acceptance testing and recurring costs.

Canonical: https://devauras.com/en/resources/website-brief-checklist
Last updated: 2026-09-11

Checklist · Website creation

Prepare the decisions that make a quote comparable: objective, content, features, responsibilities, acceptance criteria and costs to plan for after launch.

Devauras team — web design & development

Published 11 September 2026

8 min read

![An abstract editorial composition illustrating website project scoping.](https://devauras.com/images/services/creation-site-web_devauras.png)

Website creation

## The essential point

A useful website brief is not a long document filled with jargon. It describes the problem clearly enough for everyone to understand the first-release scope, the information to provide, the decisions to approve, and how to confirm the site is ready for launch.

## Key takeaways

- Start with the business result and intended visitor, not a page list.
- Separate launch-critical functions from ideas to plan later.
- Name the people responsible for content, approvals, access and enquiry responses.
- Define observable acceptance criteria before development.
- Make recurring costs and dependencies visible in the written proposal.

## 1. Objective, visitors and main action

Describe in one sentence what the site should help the business do. Avoid vague aims such as “be more visible”; instead specify the expected action, for example receiving quote requests for a given service, enabling booking, or presenting a catalogue to a professional audience.

Then describe priority visitors: what they already know, what they are looking for, their common questions and the action they should be able to take. A site can serve several audiences, but the brief should state which one takes priority when a page, message or feature conflicts with another.

### Write this in the brief

For \[priority audience\], the site should enable \[main action\] because \[need or problem\]. We will measure \[observable signal\] without promising a commercial outcome outside our control.

[Devauras: Web Design Agency in Morocco](https://devauras.com/en/services/web-design-agency)

## 2. First-release scope

A useful first release contains the pages, content and functions needed for the main journey to work properly. Anything nonessential can be placed in a later phase, with its owner and the condition that would justify adding it.

Scope table to complete before a quote

| Item | Decision to make | Owner to name |
| --- | --- | --- |
| Pages | Which pages must be ready at launch, and what is each page's main action? | Content or business owner |
| Languages | Which languages will be published at launch, and who approves each version? | Language-approval owner |
| Features | Form, booking, payment, client space, search, integration: which function is needed and for which journey? | Business and technical owner |
| Content | Which copy, images, documents, products or data are available, missing or awaiting approval? | Content owner |
| Later phase | Which ideas are wanted but not needed in the first release? | Project decision-maker |

[Devauras: Web Design Agency in Morocco](https://devauras.com/en/services/web-design-agency) · [Devauras: Pricing and quoting method](https://devauras.com/en/pricing)

## 3. Journeys, functions and exceptions

Describe the steps between a visitor arriving and the expected result. For a form, specify required fields, recipient, confirmation message, desired response time and what happens when information is missing. For payment, booking or a client space, add business rules, authorised people and error handling.

Unusual cases matter: cancellation, unavailability, duplicate request, forgotten access, incorrect data, declined payment or a request sent to the wrong team. Documenting them early helps choose the required controls and avoids promising that a journey works in every situation before it has been tested.

- **Input** — What information starts the journey, and who can provide it?
- **Output** — What does the visitor receive, and what does the team receive after the action?
- **Rule** — What is allowed, declined or sent to a person for review?
- **Exception** — What happens if data, payment, integration or availability is not as expected?
- **Evidence** — How will you check that the journey worked before and after launch?

[W3C: Web Content Accessibility Guidelines (WCAG) 2.2](https://www.w3.org/TR/WCAG22/)

## 4. Content, proof and rights

List what must be provided: offer copy, legal pages, visuals, photography, logos, product information, testimonials, downloads and translations. For each item, note its owner, approval status and the rights needed to publish it.

Commercial proof needs particular care. A case study, statistic, review or logo should be verifiable and authorised. If information is missing, keep it out of the first release rather than strengthening it with imprecise wording.

### Simple rule

Publish what you can explain and prove. Promises, client results, reviews and references must remain faithful to their source and the approval received.

[Google Search Central: Creating helpful, reliable, people-first content](https://developers.google.com/search/docs/fundamentals/creating-helpful-content)

## 5. Technology, access and ownership

The brief should identify the accounts and access involved: domain, hosting, email, analytics, tag manager, payment, CRM, booking tool and social channels when integration is planned. Decide who owns each account, who can administer access and what will be handed over at project completion.

Also state any required environments, migration, data transfer, backups, licences and fallback process if a provider must be replaced. These decisions determine whether the site can continue operating after delivery.

[Devauras: Web Design Agency in Morocco](https://devauras.com/en/services/web-design-agency)

## 6. Acceptance testing, measurement and launch

Define how the first release will be accepted. Criteria should be observable: agreed pages exist, forms send a test enquiry, priority links work, content is approved, access rights are correct and key journeys have been checked on agreed screens.

Then prepare launch: target date, owners, backup or fallback, escalation contacts where needed, analytics access and useful event tracking. A form event is an enquiry signal; it does not automatically become a client or revenue.

1. **Pre-acceptance** — The team checks scope, content, access and written test cases.
2. **Client acceptance** — The client tests agreed journeys, reports gaps and approves or requests a correction against defined criteria.
3. **Launch** — Owners confirm the window, access, tracking, backup and fallback process before any switch.
4. **Follow-up** — Useful events, enquiries and errors are reviewed after launch with their context, without jumping to a commercial conclusion.

[Devauras: Web Design Agency in Morocco](https://devauras.com/en/services/web-design-agency) · [Google Search Central: Creating helpful, reliable, people-first content](https://developers.google.com/search/docs/fundamentals/creating-helpful-content)

## 7. Make quotes genuinely comparable

Two totals are comparable only when their scopes are comparable. Ask every proposal to separate pages, languages, content, design, development, integrations, migration, hosting, licences, maintenance, client dependencies, schedule and change rules. A single “complete website” line does not state what will be delivered or what is missing.

For every difference, ask for the effect on timeline, cost and expected result. That transparency makes a decision safer than a performance promise or a price isolated from its scope.

### Before you sign

You should be able to answer four questions clearly: what is delivered, who does what, how work is accepted, and what costs remain after launch?

[Devauras: Pricing and quoting method](https://devauras.com/en/pricing)

## Frequently asked questions about a website brief

### Do you need a complete brief before requesting a quote?

No. A clear first brief is enough: objective, visitors, main action, essential pages or functions, available content, constraints and owners. Scoping can then clarify unknowns before a detailed commitment is approved.

### What should a website brief contain?

It should cover at least the objective, audiences, scope, content, languages, functions, integrations, responsibilities, acceptance criteria, schedule, access and recurring costs to confirm.

### Who should approve a website before launch?

The named project owners should approve their area: content and brand, business operation, access, applicable compliance and the final launch decision. Roles and acceptance criteria should be written before testing begins.

### How do you compare two website quotes?

Compare scope first: pages, languages, content, design, functions, integrations, schedule, maintenance, licences, responsibilities and change conditions. A price alone does not show what is included or which dependencies could change the project.

## Sources and references

- [Web Design Agency in Morocco](https://devauras.com/en/services/web-design-agency) — Devauras
- [Pricing and quoting method](https://devauras.com/en/pricing) — Devauras
- [Creating helpful, reliable, people-first content](https://developers.google.com/search/docs/fundamentals/creating-helpful-content) — Google Search Central
- [Web Content Accessibility Guidelines (WCAG) 2.2](https://www.w3.org/TR/WCAG22/) — W3C

## Related

- [Which website type should your business choose?](https://devauras.com/en/resources/choose-website-type)

## Need to make a web project clear?

Devauras helps you scope the work, journeys, dependencies and acceptance criteria before design and development begin.

[Explore web design](https://devauras.com/en/services/web-design-agency)