How to write a project brief a developer can actually quote

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.

§ 01What to include

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

§ 02What 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.

§ 03What 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.

§ 04A template to start from

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.