Website Development Brief Template: What to Send a Developer

A useful website brief tells a developer what the business needs the site to do, who will use it, what content exists, and how the team will decide the work is complete. It does not need polished copy or a perfect design. It needs enough detail to estimate scope and expose unanswered questions before they become late changes.

Copy the outline below into a document and fill in what you know. Mark unknown items as open questions. A blank field is more useful than an invented requirement.

1. Describe the business and project goal

Write a short description of the business, its main offer, and the customers it actually serves. Then choose one primary outcome for the first release: explain a service, receive inquiries, organize a product catalog, accept online transactions, or support another specific workflow. Secondary goals can be listed, but identify what matters most.

2. List the pages and content you can provide

Create a page list and write the purpose of each page. For each one, note whether the text, photos, product data, legal copy, and approvals already exist. If you have reference websites, say what you like about them—such as navigation, tone, or image treatment—rather than asking to copy another business's entire design.

• Homepage: what the visitor should understand first.
• Service or product pages: scope, options, specifications, and limitations.
• About or company profile: approved business background and team facts.
• Portfolio or proof: work the business has permission to show.
• Contact or inquiry: recipient, notification path, and expected follow-up.

3. Separate required features from ideas

Describe the user's steps, not only a feature label. “Add e-commerce” might mean product variants, inventory, shipping rules, taxes, payment providers, order emails, refunds, and staff permissions. “Add a CMS” might mean editing selected text fields or managing an entire catalog. Write what the user should be able to do and who will maintain it.

4. Define ownership, approvals, and acceptance

Name one decision-maker who can consolidate feedback. List the people who approve copy, design, technical integration, and launch. Agree on how many review rounds are included, how new work is approved, and what counts as a defect versus a change in scope.

Acceptance criteria should be testable. “Looks good on mobile” can become “on a phone, the navigation opens, the service title wraps without clipping, the contact link opens the correct channel, and the form confirmation is visible.” This reduces disagreement during handoff.

Copy-ready website brief

1. Business and current website: [name, location, URLs, accounts]
2. Primary audience and goal: [who visits, what they need, desired action]
3. Page list: [page, purpose, content owner, materials available]
4. Features: [visitor or staff action, priority, dependencies]
5. References: [what to learn from each example, what not to copy]
6. Timeline and budget: [target date, decision deadlines, approved range]
7. Ownership: [approvers, account owners, who maintains content]
8. Acceptance: [specific checks for content, design, forms, mobile, and launch]

Send the brief with the current package or pricing questions. If the business is based outside the developer's home market, confirm service availability, time-zone expectations, payment arrangements, currency, taxes, and support terms directly instead of assuming they are covered.

5. Record dependencies and risks before estimating

List anything the project depends on but does not control: access to the current CMS, domain registrar, DNS, hosting, payment provider, CRM, or product database. Note who can provide access and when. If a website must connect to another system, include the system name, the action that should happen, documentation availability, account permissions, and whether a paid plan or third party must approve the connection.

Capture important constraints in plain language. The site may need to launch before a trade show, support an existing URL structure, use content supplied by a legal team, or work with a limited hosting environment. Separate a hard requirement from a preference. This helps a developer identify risks early and propose a smaller first release if the complete scope cannot fit the available time or budget.

6. Ask for an estimate that can be compared

Request the estimate in deliverables rather than one unexplained total. Ask for included page templates, content work, initial data entry, integrations, revision rounds, training, launch support, and recurring costs. Ask the provider to name assumptions and exclusions, such as who supplies copy or whether a payment provider account is already approved. If a requirement is uncertain, have it listed as an open question with the next step needed to price it.

You can compare proposals fairly only when providers respond to substantially the same brief. If one proposal includes migration and training while another covers design and development only, the totals are not directly comparable. Use the brief to clarify the differences, then choose based on the business's actual priorities and ability to maintain the result.