A website project checklist, from brief to handoff.

A website brief is more useful when it describes what visitors and the business need to do. Use this checklist to expose decisions early, then turn the agreed priorities into a deliverable first release.

Define the job before the page list.

Name the audience, the question they arrive with and the next useful action. Distinguish a primary task, such as making an inquiry, from supporting tasks such as reviewing a service or downloading information.

Business goal and visitor task.
Required pages, languages and approval owners.
Deadline, dependencies and an initial scope boundary.

Inventory what already exists.

For a redesign, retain a list of existing pages and important inbound links. Record which URLs should stay, which should redirect and which content needs review. Identify domain, hosting, analytics and integration owners without placing passwords in the brief.

Make content and mobile review part of scope.

Agree who supplies and approves copy, photographs, product information and legal text. Test real content at narrow widths. A responsive layout needs readable text, usable menus, accessible forms and a clear path back from errors.

Navigation and content hierarchy.
Readable headings, media crops and touch targets.
Field labels, validation, error recovery and confirmation wording.

Follow the request beyond the form.

Decide which system records the request, who receives it and what counts as accepted. A CTA click is not a booked meeting. A successful network request is not proof that a CRM record or appointment exists. Test each boundary and retain a useful recovery path.

Identify the decisions that change effort.

Page count is only one cost driver. Original content, product volume, custom interactions, data migration, integrations, accessibility remediation and approval complexity can change the work. Separate project delivery from hosting, licenses and ongoing maintenance.

Make launch and handoff reviewable.

Agree acceptance criteria before the final week. Check production configuration, redirects, metadata, forms, backups and recovery. Confirm who controls the domain and source files and who will maintain the delivered result.

Test important journeys and their failure states.
Verify redirects, canonical URLs, sitemap and index settings in the intended environment.
Confirm content and asset permissions.
Document access, release steps, rollback and support responsibilities.

Questions before we begin.

How detailed should the first brief be?

It should explain the problem, audience, existing platform, key tasks and constraints. Open questions are useful when they are explicit; the first brief does not need to preselect every technical answer.

Should a redesign keep existing URLs?

Keep useful URLs where practical. Where a URL changes, map it to the relevant replacement and test the redirect rather than sending every old page to the homepage.

What belongs in the handoff?

Include ownership and access, release and recovery instructions, content-editing guidance, integration responsibilities and the agreed maintenance or support boundary.

Turn the checklist into a practical scope.

Bring the current website, the people involved and the questions you cannot resolve yet.

Discuss your project

Discuss the project scope, delivery requirements and the next useful step with Tellbyte.

Discuss your project