Website brief: the checklist to prepare before a quote

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.

Devauras: Web Design Agency in Morocco

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.

Devauras: Web Design Agency in Morocco · Devauras: Pricing and quoting method

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

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.

Google Search Central: Creating helpful, reliable, people-first 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

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. 01

   Pre-acceptance — The team checks scope, content, access and written test cases.

2. 02

   Client acceptance — The client tests agreed journeys, reports gaps and approves or requests a correction against defined criteria.

3. 03

   Launch — Owners confirm the window, access, tracking, backup and fallback process before any switch.

4. 04

   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 · Google Search Central: Creating helpful, reliable, people-first 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.

Devauras: Pricing and quoting method