How to Write a Website Project Brief

A good website project brief tells a provider what the business needs customers to understand and do, which pages and functions may support that outcome, what already exists, and which constraints affect the budget. It does not need to dictate every color, screen, or technical choice.

The best brief makes assumptions visible. It separates business facts from creative decisions, required launch work from future ideas, and the one-time build from hosting and ongoing service.

Start with what the website must accomplish

Choose one primary result:

• Generate qualified calls or form inquiries.
• Explain a complex service before a sales conversation.
• Build trust for customers comparing local providers.
• Book appointments or accept orders.
• Recruit employees.
• Support an existing sales or referral process.
• Replace an outdated site without losing search visibility.

A site can support several goals, but each page needs a clear priority. "Make it modern" describes an aesthetic preference, not the business result.

1. Business and offer

Provide the legal and public business names, years operating where relevant, service area, locations, contact methods, hours, core services or products, price context, credentials, warranties, financing, and other facts customers use to decide.

Explain which offering matters most commercially. A provider cannot structure an effective site if every service is presented as equally important despite very different demand or margins.

2. Audience and buying questions

Identify the people who make or influence the purchase. Describe their situation when they arrive, what they already know, their urgency, and the questions that block action.

Useful examples include:

• Can this company handle my specific job?
• Do they serve my address or industry?
• What will it roughly cost?
• Can they start in time?
• What proof shows they are credible?
• What happens after I contact them?

The answers determine content and page structure more than a list of competitor colors.

3. Primary and secondary actions

State the main action visitors should take: call, request an estimate, schedule, purchase, visit, apply, or download. Include the information the business needs to respond productively.

Define secondary actions for visitors who are not ready, such as viewing work, reading a service explanation, checking locations, or reviewing frequently asked questions.

4. Current website and evidence

If a site exists, include:

• URL, platform, host, registrar, and administrator access status.
• Analytics and Search Console access.
• Pages or search queries that produce leads.
• Known form, speed, mobile, security, or editing problems.
• Content that must remain, improve, merge, or disappear.
• Current recurring costs and licenses.
• Previous redesign or migration problems.

Attach representative analytics or inquiry data when available. A redesign should preserve what works, not erase it because the interface looks old.

5. Initial page inventory

List required pages and note whether each needs original content or can use existing material. A typical service-business starting point might include:

• Home.
• One overview and several priority service pages.
• About or trust page.
• Portfolio, case study, or work examples where truthful evidence exists.
• Location or service-area information.
• Frequently asked questions.
• Contact or estimate request.
• Required legal and privacy pages.

Do not duplicate pages solely to reach a target count. Every page should answer a distinct customer question or support an intentional search need.

6. Content responsibilities

Clarify who supplies and approves:

• Business facts and service details.
• Writing, editing, headlines, and calls to action.
• Logo and brand files.
• Photography, video, illustrations, and icons.
• Testimonials, reviews, and permission to use them.
• Credentials, associations, guarantees, and legal claims.
• Privacy, terms, accessibility, tax, or regulated language.

"Copy included" can mean proofreading or full stakeholder interviews and writing. Define the expected work so the quotes are comparable.

7. Design context

Provide brand guidelines, existing materials, and two or three references. Explain what is useful in each example: information density, typography, tone, navigation, photography, restraint, or interaction.

Avoid "make it look like this competitor." The website should serve the business's audience and content. Also distinguish a required brand constraint from a personal preference.

8. Functions and integrations

Name each function and its required behavior:

• Contact or estimate forms, including fields and routing.
• Scheduling, deposits, rescheduling, and confirmations.
• Ecommerce, catalog, shipping, tax, returns, and payment.
• Customer accounts or portal access.
• Calculators, search, filters, maps, chat, or document upload.
• CRM, email marketing, analytics, call tracking, or accounting connections.
• Languages, locations, memberships, or restricted content.

For every integration, name the provider and plan. A free product tier may not offer the required API or embedded behavior.

9. Search and location requirements

List the real services, customer language, locations, and service area. Provide the correct business name, address where public, phone, categories, hours, and existing business-profile URLs.

Do not request hundreds of thin city pages. Ask the provider to create a crawlable structure, specific service pages, accurate location signals, metadata, sitemap, redirects, and measurement.

For a redesign, identify current pages and queries that deserve protection. Search work cannot guarantee ranking or leads, but careless migration can destroy useful signals.

10. Migration and redirects

State what must move: pages, blog posts, media, products, customers, orders, form history, downloads, metadata, reviews, users, or structured data.

Provide the current URL inventory where possible. Require a redirect map for changed addresses and a post-launch check for broken links, missing files, crawl problems, analytics, and forms.

11. Accessibility, performance, privacy, and security

Include known contractual or policy requirements and the expected browsers, devices, languages, assistive-technology considerations, performance goals, data collection, consent, retention, and security controls.

Ask qualified professionals to determine legal requirements. The developer can implement and test the approved policy but should not invent legal conclusions.

12. Domain, hosting, accounts, and care

State who currently controls the domain, hosting, email, analytics, forms, licenses, and business profiles. Say whether the business wants to manage infrastructure, use the provider's care service, or compare both.

The guide on who should own the domain, code, and hosting provides an asset-control checklist.

13. Budget and deadline

Share a working range and the outcome that must fit. Without one, a provider may quote a $3,000 focused site, a $15,000 content-and-design engagement, or a $60,000 commerce system in response to the same word "website."

At Vertinus's $49.99 hourly rate, a $3,000 budget represents roughly 60 hours. The article on what a $3,000 website budget can build shows realistic boundaries.

Give the reason for the deadline: lease opening, campaign, event, platform shutdown, seasonal demand, or preference. Identify content and approval dates the business must meet.

14. Decision process and review

Name the project owner, final approver, content experts, legal reviewers, and technical contacts. Consolidate feedback through one responsible person.

State how providers will be evaluated: relevant reasoning, scope completeness, content plan, technical approach, ownership, schedule, recurring cost, and support. Aesthetic preference should not be the only criterion.

A copyable website-brief outline

1. Business: what we sell, where, and why customers choose us.
2. Goal: the primary website outcome and metric.
3. Audience: customer situations, questions, and objections.
4. Actions: primary and secondary visitor actions.
5. Current site: URL, platform, access, evidence, and problems.
6. Pages: required page inventory and priorities.
7. Content: who supplies, writes, edits, and approves each asset.
8. Design: brand constraints and explained references.
9. Functions: forms, booking, commerce, portal, and integrations.
10. Search: services, locations, existing performance, and migration.
11. Quality: accessibility, devices, speed, privacy, and security.
12. Ownership: domain, code, accounts, hosting, licenses, and care.
13. Budget and timing: working range, launch date, and reason.
14. Decision process: owner, approver, reviewers, and availability.

Example of a concise website brief

Business and goal: a Dallas-area commercial cleaning company wants more qualified estimate requests from property managers for recurring office service. The current five-year-old site receives traffic but produces fewer than four useful inquiries per month.

Required first site: home, commercial cleaning overview, office cleaning, medical-office cleaning with approved claims, service-area page, about, work examples using verified company material, FAQ, and estimate form. No customer portal, online payment, careers system, or ecommerce.

Content and functions: the company supplies service facts, logo, team photos, references, certifications, and service-area details. The provider shapes and edits page copy. The estimate form routes by location and sends a confirmation. Analytics and current search access are available.

Ownership, budget, and timing: the company owns its domain and wants ownership of the completed code. It is open to managed hosting. Working build budget is $3,000 to $5,000; desired launch is eight weeks; the operations manager is final approver.

That brief gives a provider enough information to identify missing evidence, propose the right page structure, and explain what fits the budget.

A brief should invite a better recommendation

Do not force providers to quote an ineffective feature list. Explain what must change for the business, then ask how they would achieve it within the constraints.

The response should make the page and content scope, assumptions, exclusions, hours, schedule, accounts, ownership, recurring costs, and measurement plan easy to compare.