How to Prepare a Website Project Brief Before Asking for Quotes

A website project brief should help you get comparable quotes, expose important decisions before work begins, and prevent a developer from guessing at the scope.

It does not need to be a long formal document. It does need to explain what business problem the website should solve, who it needs to persuade, what the visitor should do next, what must be included, and what should not be assumed.

Without that clarity, two providers can receive the same short request—“I need a modern website with SEO”—and return completely different proposals. One may include copy structure, content migration, redirects, mobile refinement, service pages, and launch checks. Another may interpret the request as a visual template setup with a contact form. The prices may look comparable, but the work is not.

This guide explains how to prepare a website project brief before asking for quotes, especially when you are planning a new website, redesign, landing page, or service-page system.

Quick decision summary

1. Start with the business problem, not design preferences. Explain what the website needs to improve or make possible.
2. Define the visitor and the next action. A website project cannot be scoped properly without knowing who it should persuade and what they should do.
3. Separate essentials from optional work. This prevents every preference from becoming an assumed requirement.
4. State content, migration, and technical responsibilities clearly. These are often the hidden differences between proposals.
5. Compare proposals by scope and assumptions before price. The lowest figure is not useful when it excludes work another provider has included.

A strong brief does not tell a developer exactly how to do their job. It gives them enough reliable information to recommend the right approach, explain their assumptions, and price the work responsibly.

Why vague website requests produce weak or incompatible quotes

Most website projects become unclear before design work starts. The owner knows that the current site feels outdated, does not represent the business well, gets weak inquiries, or is difficult to manage. Those are important signals, but they are not yet a usable project scope.

A request such as “I need a better website” leaves too many decisions unanswered. Better for whom? Better at explaining which service? Better at generating calls, quote requests, bookings, applications, or sales? Better through new copy, new page structure, a new platform, a focused landing page, or a complete redesign?

The provider then has to make assumptions. Some will ask questions. Some will send a generic package. Some will quote a narrow visual build because that is all the request appears to require. None of those outcomes gives you a dependable basis for comparison.

A better brief does not guarantee that every proposal will be identical. It gives each provider the same decision context, so you can see where their interpretation, scope, method, exclusions, and price genuinely differ.

A website project brief is not a list of design wishes

It is reasonable to include visual preferences, examples of websites you like, brand colors, or preferred styles. But those should support the project, not define it.

A website is not successful simply because it looks modern. It needs to help the business explain its value, build trust, organize services, answer important buyer questions, support search visibility, and guide the right visitor toward an appropriate next step.

The most useful brief describes the required outcome first. It then identifies the content, structure, functionality, assets, technical constraints, and approval process needed to deliver that outcome.

For example, “Make the site modern and SEO-friendly” is not a useful scope. A clearer statement would be: “The new website should help business owners understand our consulting services, direct them to the relevant service page, show credible process and experience information, and make it easy to request a consultation.”

The Eight Decisions That Make Website Quotes Comparable

You do not need perfect answers to every question before requesting quotes. You do need to identify what is decided, what remains uncertain, and who should help resolve the uncertainty. These eight decisions create a brief that is clear enough for serious providers to assess responsibly.

1. What business problem should the website solve?

Start with the real reason the project exists. Avoid general statements such as “the site is old” unless you can explain what the age of the site is causing commercially.

The problem may be that visitors cannot understand the service, the homepage does not represent the current business, the site attracts the wrong type of traffic, key pages have weak inquiry paths, the team cannot update content easily, or the current platform prevents the business from making necessary changes.

Write this section in plain language. A provider needs to understand the business issue behind the website issue.

• What is not working today?
• What business consequence does that create?
• What should be different after the project is complete?
• What would make you feel that the project was worthwhile?

For an existing site that receives traffic but produces few serious inquiries, the first need may be stronger service clarity, trust information, and visitor flow—not necessarily a complete rebuild. When the underlying problem is uncertain, start with a website audit before committing to a larger scope.

2. Who must the website persuade?

A website cannot be structured well for “everyone.” Your brief should identify the priority audience: the people most likely to become the right type of customer, client, patient, applicant, partner, or inquiry.

Describe what that person is trying to solve, what they are likely to know already, what concerns may stop them from taking action, and what they need to see before they trust the business enough to continue.

This does not require a fictional persona document. It requires useful commercial context.

• Who is the primary visitor?
• What type of problem are they trying to solve?
• What are they likely to compare before contacting a provider?
• What information would make them feel that your business is relevant?
• What objections, risks, or doubts may need to be addressed?

For example, a homepage aimed at local homeowners should not be organized like a website aimed at corporate decision-makers comparing specialist advisory firms. The audience changes the message, proof, service structure, and inquiry path.

3. What should the visitor do next?

Every important website project needs a clear primary action. That action could be requesting a quote, booking a consultation, calling, submitting an application, purchasing a service, reviewing service options, or requesting an audit.

The action should reflect the actual buying process. A visitor ready to hire may be comfortable requesting a quote. A visitor who does not yet understand the service may need to review a focused service page first. A business owner unsure whether they need a redesign, copy rewrite, or rebuild may need an audit before a project proposal makes sense.

Write down the main action the website should support, along with any secondary actions that are genuinely useful. Do not add several equal calls to action simply because the business has several contact options.

• What is the primary action?
• What information must the visitor provide?
• What should happen after they take that action?
• Which actions are secondary, and why?
• Are there any current forms, booking systems, phone routes, or email routes that must be retained or improved?

4. What pages, services, and visitor journeys are essential?

Do not ask for “a five-page website” unless you can explain what those pages need to accomplish. Page count alone is not a meaningful scope because one focused service page may require more work than several simple information pages.

Instead, identify the essential pages and the job each page needs to do. A homepage may introduce the business and route visitors to services. A service page may explain a specific offer in depth. A landing page may support one campaign, audience, and action. A contact page may collect the information needed for a serious inquiry.

Include the visitor journey where it matters. For example, a visitor may arrive through a search result, reach a service page, review evidence and FAQs, then request a consultation. That path gives the provider a better basis for planning navigation, internal links, page hierarchy, and calls to action.

• Which pages are essential for launch?
• Which services need their own pages?
• Which pages are for information, and which pages must support conversion?
• What should a visitor see before taking the main action?
• What can wait until a later phase?

For an existing website with weak service pages, the correct scope may be a strategic website redesign rather than a full replacement of every page. The brief should leave room for this distinction instead of deciding that every problem needs the largest possible project.

5. What content, proof, assets, and URLs must be retained?

Content responsibility is one of the biggest hidden differences between website quotes. A proposal may assume that the client will provide finished copy, professional photographs, service details, testimonials, logos, legal text, product data, and page-by-page approval. Another proposal may include content planning, restructuring, and writing support.

Your brief should state what already exists, what is incomplete, and what you expect the provider to help create or organize. It is better to say that the material is not ready than to leave the provider to assume that it is.

• What copy, brand assets, photographs, videos, testimonials, case studies, and documents already exist?
• What needs rewriting, organizing, replacing, or creating?
• Who will approve final content and provide required information?
• Which pages, files, downloads, or resources must remain available after launch?
• Which existing URLs need to stay the same, and which may change?

URL retention matters when an existing website is being redesigned or moved. Google recommends mapping important old URLs to their corresponding new destinations and using permanent redirects when URL changes are necessary. Add this requirement to the brief early rather than treating it as a minor launch task. Read Google’s site-move guidance.

When the primary weakness is content clarity, service hierarchy, or buyer decision support, a focused SEO website content scope may be more appropriate than paying first for visual changes alone.

6. Which technical requirements are real requirements?

Technical requirements should be included when they are connected to a real business need. This may include an existing CRM, appointment system, email platform, payment provider, membership area, protected content, analytics setup, multilingual content, accessibility requirement, booking system, or migration from one platform to another.

Do not turn every preference into a requirement. A provider needs to know the difference between “must work at launch,” “would be helpful,” and “may be considered later.”

• What platform are you using now, if any?
• Do you have a genuine reason to stay on that platform or move away from it?
• Which integrations must work at launch?
• What accounts, domains, hosting, analytics, forms, email systems, or third-party tools are already in place?
• What must the business be able to update itself after launch?
• Are there legal, privacy, accessibility, security, or industry requirements that affect the build?

It is acceptable to be undecided about the platform. State the current situation and the reason for the uncertainty. A good provider should explain whether WordPress, Wix, a focused landing page, or another approach fits the actual project rather than treating platform choice as a branding preference.

7. What is intentionally outside the first project scope?

Every project needs boundaries. A brief becomes more useful when it identifies what is not included in the first phase, even when those items may be valuable later.

This protects both sides. It prevents a provider from assuming that every future feature is included, and it prevents the owner from expecting work that was never discussed or priced.

• Which pages, services, features, or integrations can wait until phase two?
• Are there future services, locations, languages, products, or membership areas that should be planned for but not built yet?
• Are ongoing SEO, advertising, content publishing, social media, maintenance, or support outside the initial scope?
• What should the provider explicitly identify as an optional add-on rather than assume is included?

A phased project is not a weaker project. It can be a more responsible way to launch the pages and journeys that matter most first, then add work only when there is a clear reason and available capacity.

8. How will you evaluate proposals beyond price?

Price matters, but it should not be the first or only comparison point. A proposal should show what the provider believes they are delivering, what they need from you, what they have excluded, and how the project will move from discovery to launch.

Two proposals can have very different prices because one includes content planning, migration, redirects, mobile refinement, page structure, technical setup, and launch checks while another includes only page assembly. Neither is automatically wrong. The important question is whether the scope matches what the business needs.

• Does the proposal restate your business goal accurately?
• Does it identify the pages, deliverables, content responsibilities, and technical work included?
• Does it explain assumptions and exclusions clearly?
• Does it distinguish essential work from optional work?
• Does it show how feedback, revisions, approvals, and launch responsibilities will be handled?
• Does the provider ask questions that show they understand the business problem?
• Does the proposal solve the problem you described, or does it simply sell a generic package?

What not to leave vague in your brief

Some phrases appear in website requests so often that they stop being useful. They may express a real concern, but they do not tell a provider what should be planned, written, designed, or built.

Vague request	What to clarify instead
“Make it modern.”	Explain what feels outdated now and what the new presentation must improve: clarity, trust, readability, mobile use, service structure, or brand fit.
“Make it SEO-friendly.”	State which services, locations, audiences, or buyer questions matter. Clarify whether existing content and URLs need to be retained or improved.
“I need five pages.”	List the pages and the job each page must do. Explain which pages are essential for launch.
“Use WordPress” or “use Wix.”	Explain the real need: easier updates, existing platform ownership, booking tools, design flexibility, team access, or other constraints.
“We will provide the content.”	State what is ready, what is incomplete, who will write or approve it, and whether the provider should restructure or improve it.
“We need more leads.”	Define the right type of inquiry, the service you most want to sell, the current traffic or visitor problem, and the action the visitor should take.
“We need it quickly.”	State the real deadline, why it matters, what must launch by then, and which items could move to a later phase.

The purpose is not to make the brief complicated. It is to replace assumptions with useful decisions.

A practical website project brief template

Use the outline below as a starting point. Short, clear answers are better than polished language that hides what you need.

Project overview

• Business: What does the business do?
• Project type: New website, redesign, service-page improvement, landing page, or another defined scope.
• Current website: Include the live URL and current platform, where applicable.
• Main business problem: What is the website failing to communicate, support, or convert?
• Desired outcome: What should the website make easier after launch?

Audience and conversion

• Primary audience: Who should the website persuade?
• Key visitor concerns: What may stop them from trusting or contacting the business?
• Primary action: What should the right visitor do next?
• Secondary actions: Which other actions are useful, and for whom?

Pages and content

• Essential launch pages: List each page and its purpose.
• Services: Identify the services that need focused pages or clear pathways.
• Content: State what exists, what is missing, and who will create or approve it.
• Proof: List genuine testimonials, case studies, credentials, examples, or process information available.
• Migration: Identify important content, files, downloads, and URLs that must be retained or redirected.

Technical and operational requirements

• Current platform and accounts: Domain, hosting, website platform, analytics, forms, email, CRM, booking, and other connected tools.
• Must-have functionality: Features required at launch.
• Nice-to-have functionality: Useful features that may be optional or deferred.
• Update needs: What the business must be able to change after launch.
• Constraints: Required deadline, legal needs, internal approval process, technical limitations, or required integrations.

Proposal request

• Ask the provider to restate their understanding of the problem and desired outcome.
• Ask for a clear list of deliverables, assumptions, exclusions, and optional work.
• Ask who is responsible for content, approvals, testing, migration, redirects, and launch checks.
• Ask for the proposed platform or technical approach and the reason it fits the project.
• Ask for a phased option where some requirements are important but not essential for launch.
• Ask what information is still needed before a final scope can be confirmed.

How to compare website proposals fairly

Send the same core brief to each provider. This does not prevent them from making different recommendations, but it makes their differences visible.

When you receive proposals, do not compare the total figure first. Compare what each provider has understood, included, excluded, and assumed. A lower quote may be completely reasonable for a smaller scope. It becomes a problem only when you believe it includes work that is not actually listed.

Use a simple comparison table for your own review.

Comparison point	What to check
Business understanding	Does the proposal reflect the real business problem and audience, or does it read like a generic package?
Pages and structure	Are the required pages, services, navigation, and visitor paths clearly identified?
Content responsibility	Who supplies, writes, structures, edits, approves, and uploads the content?
Technical work	Are integrations, forms, analytics, access, migration, redirects, mobile testing, and launch tasks included where needed?
Scope boundaries	Are exclusions, optional items, later phases, and assumptions written clearly?
Process	Does the proposal explain discovery, design, content, development, feedback, testing, approval, and launch?
Commercial fit	Does the quoted scope solve the priority problem without adding unnecessary work or leaving essential work out?

A good proposal should make the project easier to understand. It should not make you work harder to discover what the provider is actually offering.

When a website brief is not enough

A brief is useful when you understand the business goal and can describe the project direction. It is not a substitute for diagnosis when the central question is still unclear.

For example, you may know that the website is underperforming but not know whether the real issue is service positioning, content quality, trust signals, page structure, technical limitations, search visibility, mobile usability, or the inquiry process. In that situation, asking for a redesign quote may lead to proposals built around assumptions rather than evidence.

Start with an audit or discovery step when you cannot confidently answer the following question: what must the next version of the website fix that the current version does not?

A practical website audit can identify the priority weaknesses before you decide whether the next move should be content improvement, a focused repair, a landing page, a redesign, or a fuller rebuild.

Frequently asked questions

How detailed should a website project brief be?

It should be detailed enough for a provider to understand the business goal, audience, required pages, content situation, technical constraints, priorities, and likely scope boundaries. It does not need to prescribe every design or technical decision. A clear two- or three-page brief can be more useful than a long document filled with vague preferences.

Do I need to choose WordPress, Wix, or another platform before requesting quotes?

No. State your current platform, the reasons you may want to keep or change it, and what the business needs the website to do. A responsible provider should explain why their proposed platform fits the project rather than treating the choice as automatic.

Should I include a budget in a website project brief?

A realistic budget range or spending constraint can help a provider recommend an appropriate scope or phased approach. When you do not want to share a range, ask for essential and optional work to be separated clearly so you can understand how different scope choices affect the proposal.

Do I need to have all website content ready before asking for quotes?

No. But you should explain what content exists, what is incomplete, and whether you expect content planning, restructuring, writing, or editing support. Do not let a provider assume that all copy and assets are ready when they are not.

How can I make sure website quotes are comparable?

Give each provider the same core brief and ask them to identify scope, deliverables, assumptions, exclusions, content responsibilities, technical work, process, and optional phases. Compare those details before comparing the total price.

Should I request an audit before a website redesign?

Request an audit when you are not sure what is actually weakening the current website. It can prevent a redesign from becoming a newer-looking version of the same unclear service message, weak trust structure, or broken inquiry path.

The practical next step

Before requesting website quotes, write down the business problem, target audience, essential pages, content situation, required functionality, and project boundaries. Then ask providers to explain how their proposal addresses those needs.

For a new WordPress website, Wix website, redesign, landing page, or website-content project, send the brief through the contact page. Include your current website URL where one exists, the service you want the new site to support, the audience you are trying to reach, and the outcome you need the project to achieve.

A stronger brief does not remove every question. It makes the important questions visible before they become expensive assumptions.