# How to write a project brief a developer can actually quote

> Vague briefs get vague quotes. Nine short sections that give a team enough to estimate honestly — with a template you can copy.

By Odd Birds Studio · 27 Oct 2026 · Planning · 2 min read

If three teams quote the same brief and the prices are wildly apart, the brief is usually the problem. Each team filled the gaps with its own assumptions. A good brief does not need to be long — it needs to close those gaps.

## What to include

1. Who you are, in two or three sentences.
2. The problem — what is not working today, and for whom.
3. Who will use the result, and what they need to get done.
4. What success looks like, ideally something you could measure.
5. Must-haves for the first release, kept separate from nice-to-haves.
6. Examples you like, and what specifically you like about each.
7. What content exists already — text, photos, product data — and who will write the rest.
8. A budget range. Even a rough one changes the conversation.
9. The deadline, and the reason behind it.

> **Why share a budget?**
>
> A budget range is not a negotiating weakness. It tells the team which of several reasonable solutions to propose — the same goal can be met at very different price points, and without a range they have to guess.

## What to leave out

You do not need to choose the technology, draw every screen or write a technical specification. Describe the problem and the outcome; leave the how to the people you are hiring, and judge them on the quality of their questions.

> The best briefs describe the problem in detail and the solution only lightly.

## What a good team does with it

A thoughtful team will come back with questions before a number. That is a good sign: it means they are reading the brief closely rather than matching it to a price list.

- They restate the problem in their own words, so you can check they understood it.
- They point out what is unclear, risky or likely to change.
- They suggest what could be left out of the first release.
- They explain what the estimate includes — and what it does not.

If a quote arrives within minutes with no questions at all, ask what assumptions it is based on.

## A template to start from

**Project brief**

```text
PROJECT BRIEF

1. About us
   (Two or three sentences on who you are and what you do.)

2. The problem
   (What is not working today, and for whom?)

3. The people who will use it
   (Who are they, and what do they need to get done?)

4. What success looks like
   (How will you know this worked, six months after launch?)

5. Must-haves for the first release
   -
   -

   Nice-to-haves for later
   -
   -

6. Examples we like
   - Link — what we like about it:
   - Link — what we like about it:

7. Content
   (What exists already? Who will write or supply the rest?)

8. Budget range
   (A rough range is fine.)

9. Deadline
   (The date, and the reason behind it.)
```

Fill in what you can and leave the rest as questions. An honest “we don’t know yet” is far more useful to a team than a confident guess.