A website project brief a developer can use

The short answer

Describe the business problem, the people using the site and the action that must work at launch. Let the developer recommend the implementation.

Start with the decision behind the project

Write down why the website needs work now. A useful reason might be that customers cannot understand the services, staff copy enquiries between tools or the current site is difficult to update. "We need a modern website" gives a developer little to estimate because modern can describe almost any layout or technology.

Name the result the business needs. You may want more qualified appointment requests, fewer repetitive calls or a credible place to send prospects after a meeting. One primary result helps the team decide what belongs in the first release.

Describe the people who will use it

A clinic patient checking timings on a phone has different needs from an operations manager reviewing a dashboard on a laptop. Describe the main visitor in a few sentences: what they already know, what they need to confirm and what may stop them from taking action.

Include a second audience only when that group needs a different route through the product. Staff, partners and returning customers often need separate information or permissions. Naming those differences early prevents a simple marketing site from turning into an unplanned portal halfway through development.

Document what exists today

List the current domain, website, booking tool, spreadsheets, payment provider and business profiles connected to the project. Add who controls each account. A developer can then see which systems need to stay, which data must move and where access may delay the launch.

Screenshots and links are useful. Explain what works as well as what causes trouble. Rebuilding a familiar workflow without understanding why staff rely on it can replace one problem with another.

• Current website and domain registrar
• Hosting, email and analytics accounts
• Booking, payment, CRM or messaging tools
• Content, photographs and brand files already available
• The person responsible for approving copy and design

Define the launch action

Choose the action a visitor must be able to complete on launch day. Examples include calling the business, requesting an appointment, submitting a project brief or buying a defined product. Write the steps from the visitor arriving to the business receiving the request.

Add the information the visitor needs before acting. Service boundaries, price factors, availability, location and evidence of previous work often matter more than decorative sections. This becomes the first content outline and the basis for testing the site.

Separate requirements from ideas

Mark each requested feature as required for launch, useful later or still uncertain. This gives the developer room to quote a focused first version and price optional work separately. It also exposes features that depend on an account, API or content source the business does not yet control.

Avoid prescribing technology unless your team must maintain a specific stack. State the constraint instead. "Our staff need to edit service pages without code" is more useful than choosing a content management system before the workflow is understood.

Use this copy-paste brief

Paste the headings below into an email or document. Two clear paragraphs under each heading are enough for an initial conversation. Attach the source files and links mentioned in the current-state section rather than embedding private credentials in the brief.

• Business and project: what the business does and why this project is happening now
• Primary audience: who they are, what they need and what may block them
• Launch outcome: the main action that must work and how the business receives it
• Required pages and functions: launch needs, later ideas and uncertain items kept separate
• Current systems: website, domain, tools, data and account owners
• Content responsibility: who supplies, writes and approves text, images and legal information
• Timing and budget: any fixed date, approval schedule and a realistic spending range
• Ownership after launch: who updates content, handles enquiries and approves maintenance work

Compare proposals against the brief

A proposal should explain the pages and functions included, what you must supply, what remains optional and who owns the finished accounts and code. Check whether testing, redirects, analytics, deployment and a post-launch period are included. Ask for assumptions to be written down when a price depends on content volume or a third-party integration.

The cheapest proposal may describe less work, while the most expensive may include features that do not support the launch outcome. Compare each response against the same brief and ask how the proposed scope helps the primary visitor complete the main action.