How to write a project brief that gets you better quotes (with a template)

Before anyone can quote for your website or app, they need to understand what you want. Usually that understanding is pieced together from a phone call, a few messages and some guesswork. Then each person you speak to guesses differently, and the quotes you get back are impossible to compare.

A project brief fixes that. It’s a short document, written by you, that explains what you need and why. You send the same brief to everyone you’re considering, so their quotes answer the same question.

A good brief doesn’t need to be long or technical. You don’t need to know how websites are built. You need to know your business, your customers and what you’re trying to achieve, and you already do.

Why a brief is worth the effort

Better quotes. When everyone quotes against the same written brief, you can compare prices fairly, and the quotes are more accurate because there’s less guessing. (For how to read the quotes you get back, see What a website quote should include.)

Better conversations. A brief lets the people you talk to spend the first meeting asking good questions, rather than collecting basic facts.

Clearer thinking. Writing it down forces decisions you’d otherwise put off. What’s essential? Who’s it really for? What does success look like? Many people find the brief changes their idea of the project.

Agreement on your side. If several people in your business have a say, the brief is where you agree before you talk to anyone outside.

A reference later. During the project, the brief is a reminder of what you set out to do, and it helps keep everyone focused when new ideas arrive.

What to put in it

Here are the sections that matter, roughly in order. Not every project needs every section; skip the ones that don’t apply.

1. About your business

A few sentences. What you do, who your customers are, and what makes you different. Anyone working on your project needs to understand your business before they can help it.

2. The problem or opportunity

This is the most important section. Describe why you want this project, not just what you want. For example:

• “Most of our enquiries come through WhatsApp, and they get lost when the person who holds the phone is away.”
• “Customers can’t see our prices without calling us, and we think we’re losing people who want to compare quickly.”
• “We track orders in three spreadsheets, and mistakes are reaching customers.”

A clear problem lets the people you talk to suggest better solutions, sometimes simpler and cheaper ones than you had in mind.

3. Goals

What should be different once the project is done? Be as specific as you can, but don’t invent numbers you can’t measure. Good goals sound like:

• “Customers can book and pay a deposit without contacting us.”
• “Our team can update prices and photos without asking a developer.”
• “We can see every open enquiry in one place, with who’s handling it.”

If you already measure things, such as enquiries per month or time spent on a task, include the current figures. They’ll help you judge the result later.

4. Who it’s for

Describe the people who’ll use it. Customers, staff, or both? What do they need to do? What devices do they use? Are they comfortable with technology? Do they often have a weak connection? Are any of them likely to use assistive technology, or to read in a second language?

This section shapes the design more than any other.

5. What it needs to do

List the features or pages you think you need, and sort them into three groups:

• Must have: the project fails without these.
• Should have: important, but you could launch without them.
• Nice to have: only if time and budget allow.

Sorting forces useful decisions, and it helps people quote options: a price for the essentials, and what the extras would add.

Describe features in terms of what people do, not how it’s built. “Customers can see which dates are available and book one” is more useful than “a booking calendar plugin”.

6. What exists already

• Your current website or app, if you have one. What works, and what doesn’t?
• The domain name, hosting and any accounts, and whose name they’re in.
• Brand materials: logo, colours, fonts, guidelines.
• Content: text, photos, videos, product information. Is it ready, or does it need to be created?
• Other software you use that this needs to work with: accounting, bookings, payments, stock, customer records, email, WhatsApp.

Connections to other systems are often where the real work is, so list them even if you’re not sure they matter.

7. Content

Who will write the text and provide the photos? If you’d like help with either, say so now. It’s one of the most common things left out of quotes and one of the most common reasons projects are delayed.

8. Examples you like, and don’t like

Links to websites or apps you like, with a sentence on what you like about each one. It might be the layout, the tone, how easy it is to find things, or how fast the checkout is. Examples you dislike are just as helpful.

This isn’t asking anyone to copy another site. It’s the quickest way to share taste.

9. Budget

Many people leave this out, worried they’ll be charged whatever they say. But a budget range is one of the most useful things you can include. The same project can be done in very different ways at very different prices, and without a range, the people quoting have to guess which one you want.

A range lets them tell you what’s realistic for that money, and what they’d prioritise. If your budget is well short of what you want, it’s better to find out now.

Also mention running costs you’re comfortable with, such as hosting, subscriptions and ongoing care.

10. Timing

When do you need it, and why? A fixed date, like a launch event, a season or a product release, is very different from “as soon as possible”. If there’s a real deadline, say so, and say what happens if it’s missed.

Also mention times when your team won’t be available to give feedback, like a busy season or holidays.

11. Who decides

Who will give feedback, and who makes the final decision? Projects slow down when feedback comes from many people with nobody to settle disagreements. Naming one decision-maker helps everyone.

12. How you’ll choose

It’s fair, and helpful, to say how you’ll decide between the people you’re asking: price, experience with similar projects, the approach they suggest, timing, how well they understand your business. Also say when you’d like quotes by, and when you expect to decide.

If you’re replacing something that exists

Briefs for a redesign or a replacement need a little extra, because the new thing has to take over from the old one without losing anything.

• What works now. Pages people use, features customers rely on, things your team would miss. It’s easy to lose something good in a rebuild simply because nobody mentioned it.
• What doesn’t. Complaints from customers and staff, and the jobs that take longer than they should.
• What you know about usage. If you have analytics, include the most visited pages and how people arrive. If you don’t, say so.
• Addresses that must keep working. Pages that are linked from elsewhere, printed on materials or ranking well in search. When a website is rebuilt, old addresses should redirect to the new ones, so links and search rankings aren’t lost.
• Data that must come across. Customers, orders, products, articles, subscribers. Where it lives now, and roughly how much there is.
• Accounts and access. Who holds the domain, hosting and other accounts today. If you’re not sure, find out before you start; Who owns your code? explains how.

Common mistakes

Describing the solution instead of the problem. “We need an app” tells a developer much less than “our delivery drivers can’t update orders when they’re out”. The second invites the best answer; the first closes it off. (If you’re unsure what to build, Website, web app or mobile app? may help.)

Listing everything as essential. If everything is a must-have, nothing is. Be honest about what can wait.

Being too vague. “A modern, professional website” describes almost every website. Say what makes yours particular to your business.

Being too technical. You don’t need to specify technologies. Leave that to the people you hire, and judge their suggestions on how well they explain them.

Leaving out the awkward parts. The difficult customer type, the unusual process, the old system that has to keep running, the colleague who has to approve everything. These come up eventually. It’s better they come up before the quote.

Making it very long. A brief isn’t a specification. Two to four pages is plenty for most projects. The detail gets worked out together once you’ve chosen who to work with.

A template you can copy

Copy this into a document, fill in what applies, and delete what doesn’t.

Project brief: [name of project]

About us. [What we do, who our customers are, what makes us different.]

The problem. [What isn’t working today, or what opportunity we’re missing. Why now?]

Goals. [What should be different when this is done. Any current figures we measure.]

Who it’s for. [Customers, staff or both. What they need to do. Devices, connections, comfort with technology, accessibility needs, languages.]

Must have. [List]

Should have. [List]

Nice to have. [List]

What exists already. [Current website or app; domain, hosting and accounts and whose name they’re in; brand materials; other software this needs to work with.]

Content. [Who writes the text and provides photos. Do we want help?]

Examples. [Links, with what we like or dislike about each.]

Budget. [A range for the build, and what we’re comfortable spending each month or year to run it.]

Timing. [When we need it, and why. Any times we’re unavailable.]

Decisions. [Who gives feedback and who makes the final decision.]

How we’ll choose. [What matters most to us, when we’d like quotes by, and when we’ll decide.]

Contact. [Name, role, email and phone.]

A short example

Here’s how the first few sections might look for a made-up business: a small bakery that takes custom cake orders.

About us. We’re a family bakery. Most of our income comes from custom cakes for birthdays and weddings, ordered one to four weeks ahead.

The problem. Orders arrive by WhatsApp, phone and in person, and we keep them in a notebook and a spreadsheet. We’ve double-booked busy weekends and occasionally missed a detail, like an allergy or the wording on a cake. Customers often ask for prices before ordering, and answering takes a lot of our time.

Goals. Customers can see our cake options and starting prices, choose a date that’s available, and place an order with a deposit, without having to message us first. We can see every order for the week in one place, with all the details.

Who it’s for. Customers, mostly ordering on their phones. Our three bakers, who’ll check orders on a tablet in the kitchen.

Must have. Cake options with starting prices and photos; an order form that collects date, size, flavour, wording and allergies; a limit on orders per day; deposits by card or mobile money; an order list for the kitchen.

Notice that it doesn’t mention any technology. It describes the business, the problem and what needs to happen. That’s all anyone needs to give a thoughtful answer.

After you send it

Expect questions. Good suppliers will ask them, and the questions they ask will tell you a lot about how they think. Answer the same questions for everyone if you can, so the quotes stay comparable.

Then, when the quotes come back, use your brief to compare them: did each one address your problem, your must-haves and your constraints? Did anyone suggest a better approach? Did anyone ignore something important?

Send it to us

At Variance, we read every brief carefully and reply with questions before we quote, because a good quote starts with understanding the problem. If your brief is still rough, that’s fine. Send what you have and we’ll help you shape it.

Send us your brief, or use the template above to write one. Even if you choose someone else, you’ll get better quotes for having written it.