Resources / Website brief

A website brief
you can keep.

A few useful choices. Clear responsibilities. A starting point you can share.

Three short chapters. Skip anything you haven’t agreed. No signup.

Read the handover guide

Your draft stays in this page. Closing or refreshing clears it.

Use this blank worksheet to circle your preferences. Leave anything undecided as “To agree”. Nothing is submitted.

What should someone do here?

Choose the main job. You can refine it with your supplier later.

What needs a place?

Pick the essentials. Start small; a page is a job, not a quota.

What needs to connect?

Select the jobs that need another service. Nothing chosen is still a valid starting point.

Who will bring the content?

Think words, images and permissions. Name a role first; agree the person later.

Who can say it’s ready?

One clear approval route helps the work keep moving.

Who should hold the keys?

Domain, hosting, source and service accounts need an explicit owner. Access and legal rights are separate.

Who will keep it current?

Decide who makes everyday updates, and what training or access they need.

How will you get it back?

A backup needs a responsible owner and a tested restore. This records your preference; it does not verify a backup.

Are the ongoing costs clear?

Include hosting, domains, tools, licences and support. Leave actual amounts out until confirmed.

Who helps after launch?

Agree included work, response times and the point where extra work starts.

Add a public project note (optional)

Up to 240 characters. Use public project details or roles. Keep credentials, personal details and private source material outside this brief.

The handover guide / Read, use, keep

A website should
stay useful to you.

Start with the customer’s task, then agree the smallest useful scope. A brief makes decisions visible. It does not settle legal rights or prove that a supplier has delivered.

Scope / One useful task

Start with the person.
Then make the page.

A fictional repair business, with one customer task to make clear.

  1. 01 / Customer task

    Can you repair my item?

    A customer needs to understand whether the service fits their problem.

  2. 02 / Essential page

    Explain the service.

    A service page answers that question and gives a clear next step.

  3. 03 / Responsible owner

    Keep the answer current.

    A named content lead checks the offer, details and enquiry route.

Agree the smallest useful scope before adding more pages.

Handover / Show it working

Something you receive.
Something you can use.

Name an owner and the evidence for each checkpoint.

  1. 01 / Agree

    Write down the terms.

    Record scope, recurring costs, support and permissions.

  2. 02 / Receive

    Find what you need.

    Confirm accounts, editable files and content exports.

  3. 03 / Demonstrate

    Make a routine edit.

    Ask the agreed owner to complete an everyday update.

  4. 04 / Recover

    Practise the way back.

    Test backups and a restore or migration rollback where relevant.

Use the complete checklist below. A handover checklist does not establish legal clearance.

Ownership and handover checklist

  • Domain: agree the registrant, renewal owner and transfer route.
  • Hosting and accounts: record owners, billing responsibility and secure access handover. Keep credentials outside this brief.
  • Source and content: agree which files, repositories, editable assets and exports you receive, and in what formats.
  • Rights: confirm authorship, licences and contractual/IP permissions separately from account access.
  • Editing: confirm roles, training and a demonstrated routine update.
  • Recovery: agree backup ownership, frequency, retention and a tested restore; assign migration and rollback testing.
  • Costs: list recurring services, renewal dates, dependencies and who pays; confirm amounts with the supplier.
  • Support: define included work, contact route, response expectations, ongoing ownership and exit arrangements.

Questions for your supplier

  1. Who controls the domain, hosting, source repository and connected accounts, and how will access be handed over?
  2. Can we export our content and source? In which formats, and what will another supplier need?
  3. Which dependencies, licences and recurring costs remain after launch, and who pays for each?
  4. What exactly is included in handover: files, documentation, training, access and a demonstrated edit?
  5. Who tests migration, backups, restore and rollback, and how will we see that they work?
  6. Which contractual and intellectual-property permissions cover the source, content, images and third-party assets?
Ownership / Three separate checks

A login is only
one part of it.

  • Access

    Who can use it?

    Confirm who can sign in, edit, invite people and recover the account.

  • Authorship

    Who made it?

    Identify who created the words, photographs, artwork and code.

  • Rights & licences

    What may you do with it?

    Confirm what can be used, changed or transferred, and on what terms.

Access does not establish authorship, ownership or permission. Confirm each separately.

Three different things to confirm.

Account access lets someone use a system. Authorship identifies who made something. Contractual rights and licences define how it can be used or transferred. Confirm each separately; a login is not proof of ownership or permission.

For each “To agree”, name a responsible person, the next conversation and the evidence you need. Use secure channels for credentials and access invitations.

Methods behind the brief

Original Still Matter worksheet, informed by GOV.UK’s guidance on user needs and Airbnb’s staged listing guidance. These references do not validate this tool.

Still deciding what to change? Find your next move.