A project brief is a one or two page document that says what you are making, who it is for, what is not included and how everyone will know it is done. Write it before you quote or start. It settles the arguments about scope while they are still cheap.
Most client projects do not go wrong because the work was hard. They go wrong because nobody agreed on what the work was. A client asks for "a new website", you both nod, and three weeks later you are arguing about whether the booking system was ever part of the deal.
Why the brief is the cheapest protection you have
A brief is cheap protection because it turns a vague idea into a list you can check. Project Management Institute guidance on scope statements makes the same point: writing down what is out of scope helps manage stakeholders' expectations and can reduce scope creep. PMI's article on scope statements is worth a read if you manage larger jobs.
Scope drift is common and it costs money. Ignition's 2025 agency report found 57% of agencies lose $1,000 to $5,000 every month to scope creep. Expectations that are not written down drift, and they drift towards more work for the same fee.
A brief also catches expensive misunderstandings while they are cheap. A correction in a brief costs a sentence. The same correction after delivery costs hours or days.
There is a quieter benefit as well. A structured brief makes you look like a professional. Clients who have been burned before notice immediately when someone arrives with a clear document instead of "sounds great, when do we start?" It sets the tone for the whole relationship.
What a project brief includes
A brief does not need to be long. It needs to be complete. These sections earn their place.
Goals and the problem being solved
Start with why the project exists. Not "redesign the homepage" but "the current homepage converts poorly and the client wants more demo bookings". Goals keep both of you honest later, when a request comes in that looks shiny but does not serve the real objective.
Audience
Written by
The Delivvo team
Delivvo runs the client cycle for service businesses: inquiry, quote, contract, deposit and delivery. Payments go straight to your own account.
You can keep a client in a distant time zone happy without answering messages at 3am. This post covers async-first habits, how to find and protect an overlap window, the tools that carry the load, and what to put in your contract about response times.
Egyptian freelancers can get paid by clients abroad, but the options are narrower than in some countries and the pound's recent history makes currency a real decision. This guide covers what Payoneer, Wise, PayPal and bank transfer can and cannot do, and how to set up a cheap, steady way to receive money.
If you are self-employed and use part of your home only for work, you can deduct it on your US return. This post covers who qualifies, the simplified and regular methods with a worked example, the mistakes that cause trouble, and the records to keep.
8 min read
Your inquiry link is free.
Free plan. No card needed.
Blog
Guides for service businesses, from the first inquiry to the final payment. Written by the team behind Delivvo.
Who is this for? Asana's guide to creative briefs lists audience as a core element next to goals, messaging, deliverables, budget and timeline. A landing page for procurement managers is a different object from one for teenagers, and you want that decided before you design anything.
Scope and deliverables
This is the heart of the brief. List the concrete things you will hand over: five page designs, one logo with three variations, a 1,200 word article, a working checkout. Be specific about quantity. "Some social graphics" is a future argument. "Six social graphics sized for Instagram and LinkedIn" is a boundary.
What is out of scope
Name the things people might assume are included but are not. Copywriting when you were hired to design. Hosting setup when you were hired to build. Ongoing maintenance after launch. This section feels awkward to write and saves the most grief.
Deadlines and milestones
When is the final due, and what are the checkpoints? Tie each milestone to a deliverable so progress is visible and not a black box until the end.
Budget and success criteria
You do not always put a number in the brief, but you should write down how the client will decide the project was a good result. Vague success criteria are how competent work still gets called a failure.
Constraints and what you need from the client
List the brand guidelines, logins, copy, photos and approvals you need, and who will supply each one. Many delays trace back to a client who has not sent the thing you are waiting on. Naming it in the brief makes the dependency their responsibility, in writing.
A freelancer reviewing a project brief outline on paper
How to get a brief from a client who has not written one
Most clients will not hand you a brief. They send a paragraph in an email and a lot of enthusiasm. Your job is to turn that into structure, and you do it by asking questions before you quote.
Ask what success looks like in ninety days. Ask who the work is for and who makes the final decision. Ask what already exists that you should reuse, and what they have tried that did not work. Ask, specifically, what is not part of this. Clients rarely volunteer exclusions, but they will confirm them when you propose them. A ready-made list of questions is in the client intake questionnaire template.
Then you write the brief, not them. Send it back as "here is what I heard, please correct anything wrong." That flips the dynamic. Instead of waiting for a perfect brief that never arrives, you produce a draft and the client reacts to it. People edit more easily than they author, and a client who corrects your draft has effectively agreed to the scope.
This is also where you catch silent assumptions: the five-page site the client pictured while you priced three, or the "quick logo" that secretly needed a full brand system. It is better to surface those in a document than in an invoice dispute.
A reusable brief structure
You do not need special software. A shared document works. Use the same headings every time:
Project name and a one-line summary a stranger could understand.
Goals: two or three measurable outcomes.
Audience: who the work serves, in enough detail to guide design and tone.
Deliverables: a numbered list with quantities and formats.
Out of scope: a short list of nearby things that are not included.
Timeline: the final deadline and milestones tied to deliverables.
Budget and success criteria: the agreed range and the measure of a good result.
Client responsibilities: assets, access and approvals, with owners and rough due dates.
Keep it to a page or two. A brief nobody reads is worse than none, and length is the enemy of getting it read. Upwork's own guidance on briefs makes the same point from the client side: the more useful information a client puts in, the fewer questions come back later. Upwork's guide to creative briefs is a good outside check on your template.
Once the brief is agreed, it feeds the statement of work, where the shared understanding hardens into deliverables and acceptance terms. It also gives you a fixed reference when someone asks for more. When a new request lands, you can ask the only question that matters: was this in the brief? That is the first move in stopping scope creep.
Keeping the brief alive after the project starts
A brief is not a document you file and forget. Its best use comes mid-project, when the client asks for something. You open the brief and check. If it is in scope, you do it. If it is not, you have a calm, written basis for a talk about timeline and budget.
That only works if both sides can find the document. Keep it where the client already looks, next to the files, the approvals and the contract. A brief that sits in an old email thread protects nobody.
Payment can follow the same logic. Bonsai's invoice data found 29% of freelance invoices are paid at least a day late, and disputes about what was delivered are one reason. A brief that the client agreed to gives you a clear answer when someone says "this is not what I expected".
A brief is not legal advice and not a contract. For anything with real money or rights at stake, have the contract checked by a lawyer.
How Delivvo keeps the brief next to the work
Delivvo is built so the brief, the quote, the contract and the deliverables all sit in one place the client can open.
The brief starts with an inquiry form at delivvo.io/f/yourname. The form builder has 26 field kinds, up to 40 fields and a file field, so the client can describe the job and attach references in their own words. It works in English and Arabic.
The answers land on your lead board as a card. You read the brief and reply from there.
You turn the agreed scope into a quote built from packages and add-ons, with the out-of-scope items written in. On Pro, the client picks, signs and pays the deposit on one page.
Delivvo creates the client, project, contract and invoice from that one acceptance, so the scope the client agreed to is the scope on the contract.
Inside a team workspace, each task has an assignee, a brief, a due date and files, so the person doing the work sees the same brief the client agreed to. The client only sees the approved file under your business name.
In the client portal, the client opens a project with a one-time code and finds the documents, files, versions and messages together. When a new request arrives, you point to the agreed scope and send an add-on quote.
The signing record on each contract keeps a SHA-256 hash, the IP address, the device and an archived PDF. Every quote and contract has a verification code. The client pays through your own gateway and Delivvo takes 0%.
Free covers 3 clients and 3 active projects with no card. See the inquiry forms and proposals pages.
FAQ
Is a project brief the same as a contract?
No. A brief captures the shared understanding of what the work is, who it is for and how success is measured. A contract covers payment, ownership and liability. The brief usually comes first and informs the contract and the statement of work.
How long should a project brief be?
One to two pages for most projects. A brief that is too long does not get read. Cover goals, audience, deliverables, exclusions, timeline and client responsibilities, then stop.
What if the client will not engage with a brief?
Write it yourself from their email and your discovery questions, then send it back for confirmation. Frame it as what you understood and ask them to correct anything wrong. A client who corrects your draft has agreed to the scope without having to write a document they were never going to write.
Does a brief really stop scope creep?
It does not stop clients from asking for more. It gives you a written baseline to measure new requests against. Naming what is out of scope turns a vague disagreement into a yes-or-no check against an agreed list.
Delivvo runs the whole client cycle for service businesses, from the first inquiry to the quote, contract, deposit, invoice and delivery, so the scope the client agreed to stays in front of both of you for the whole project. Clients pay you directly through your own gateway, and Delivvo takes 0%. Start free
