Project Brief Example: 3 Complete, Filled-Out Briefs You Can Copy

You have read a dozen posts on what a project brief "should" contain. Goals, scope, success criteria, the lot. What none of them show you is a finished one. So you open a blank template, stare at the field labels, and write the same vague filler your clients give you.

This post is the part that usually gets skipped: actual filled-in briefs. Three of them, for three real-shaped projects an agency or freelancer would plausibly take on this year. A small bakery website, a booking platform for a physio clinic, and an internal stock-tracking tool for a trades business.

Each one is written the way I would write it after a proper scoping conversation. Names and a few details are invented, but the structure, the level of specificity, and the open questions are exactly what a usable brief looks like. Copy the shape, swap in your own project, and you have a head start. After each example there is a short note on why it works, because the format only helps if you can see the thinking behind it.

What a project brief looks like before we get specific

Every brief below follows the same six-part skeleton. It is worth seeing the skeleton on its own once, because the rest of the post is just this filled in three different ways:

1. 1Goal. The business outcome, not the deliverable. "Stop losing custom-cake orders in Instagram DMs" tells you more than "build a website".
2. 2Target users. Who actually touches the thing, described concretely enough that you can picture them and the conditions they use it in.
3. 3Scope, split into in and out. A short list of what this phase delivers, and an equally short list of what it deliberately does not. The "out" list does the heavy lifting.
4. 4Technical notes. What is already decided: platforms, integrations, existing accounts, data rules. Anything that constrains how you build before you start.
5. 5Timeline. A realistic window with one or two milestones, plus any hard date the work is anchored to.
6. 6Open questions. The decisions not yet made, written down and owned, so they get resolved on purpose instead of resurfacing as a change request in week four.

The difference between a brief that protects you and one that does nothing is almost entirely in how specific these fields get. Compare the same "goal" field written two ways:

The first sentence could describe any project ever commissioned. The second one you could measure in a month. Hold that standard against every example below.

Example 1: A bakery website

A two-location artisan bakery in Bristol. They are not trying to become an e-commerce store. They are trying to stop a specific, daily annoyance: custom cake enquiries arriving as Instagram DMs that get lost while the counter is busy.

Example 2: A booking platform

A four-practitioner physiotherapy clinic that takes bookings entirely by phone. Reception is drowning, no-shows are costing real money, and patients increasingly expect to book at 9pm without ringing anyone. This is a bigger, riskier project than the bakery, and the brief reflects that by being honest about constraints.

Example 3: A small internal tool

Not every brief is for a client-facing product. This one is an internal tool for a twelve-van electrical contractor whose van stock lives in a shared spreadsheet that is permanently out of date. The interesting constraint here is the environment: electricians, gloves on, poor signal, no patience for software.

What the three examples have in common

A bakery site, a booking platform, and a stock tracker have almost nothing in common as products. As briefs, they are nearly identical. Strip the topics away and the same four habits show up every time:

1. 1The goal is an outcome, never a deliverable. None of them say "build an X". They say what changes when it exists: orders stop getting lost, no-shows drop, the office trusts the stock count. That single sentence is what every later request gets measured against.
2. 2The out-of-scope list is as deliberate as the in-scope list. Each brief names what it is not doing. That is where most scope creep gets stopped, because a request for something on the "out" list is visibly a change, not an assumption.
3. 3Constraints are surfaced, not discovered. The Cliniko API, the ageing counter iPad, the no-signal basements. The awkward technical realities are in the brief, not waiting to ambush the build halfway through.
4. 4Open questions are written down and owned. Every brief ends by admitting what is still undecided. Naming an open question is not weakness; it is the difference between resolving it on purpose and tripping over it later.

If you want the reasoning behind this format in more depth, two companion posts go deeper: how to write a project brief clients actually fill out covers how to extract these answers from a client who would rather just call you, and how to prevent scope creep before the project starts explains why the out-of-scope line and open questions matter so much.

The hard part isn't the template, it's filling it in

Here is the thing nobody admits when they hand you a project brief template: the blank form was never the problem. You could sketch these six fields on a napkin. The problem is getting a busy client to give you answers as specific as the ones above, instead of "make it modern and easy to use".

Pulling that level of detail out of someone usually takes a real conversation, the patience to ask one follow-up question at a time, and the discipline to keep going when they say "it should just work". That is exactly the gap ReqBrief was built to close. Instead of sending a blank template and hoping, you send a link. It interviews your client one question at a time and turns their answers into a structured brief (goals, users, scope, constraints, timeline, and open questions) shaped like the three examples above. You start the project with the filled-in version, not the empty form.

Frequently asked questions