When a freelance project goes wrong, the post-mortem almost always leads back to the same place: the brief. Not to bad faith, not to incompetence, but to a document that described an outcome the client could picture and the freelancer could not. Everything downstream — the estimate, the timeline, the arguments about whether something was "included" — inherits that ambiguity.
A good brief is not long. It is specific in the places where being vague is expensive. This is what those places are.
Start with the outcome, not the task
The most common opening line of a bad brief is a task: "I need a WordPress site." The most useful opening line is an outcome: "We get about forty enquiries a month by phone and want people to be able to book directly instead." The second version lets an experienced freelancer tell you that half of what you were about to commission is unnecessary, and that something you did not mention is the actual bottleneck.
This is not a formality. Freelancers who are worth their rate are being paid partly for judgement, and judgement needs the problem, not just the instruction. If you only supply the instruction, you have hired a pair of hands and you own every decision yourself.
Say what already exists
Nothing inflates a quote faster than uncertainty about what a freelancer will find when they open your system. An estimate against an unknown codebase carries a risk premium, and it should — the freelancer is pricing the possibility that your "small change" sits inside something unmaintainable.
- Links to the live site, app, or system, including staging if there is one
- What it was built with, if you know — and "I do not know" is a legitimate and useful answer
- Who built it and whether they are still available for questions
- What documentation, tests, or handover material exists
- Anything previously attempted and abandoned, and why
That last point saves more money than the rest combined. If two freelancers already failed to fix something, the third needs to know before quoting, and hiding it does not make the problem smaller.
Define done
The single sentence that prevents the most disputes is a description of the state in which the project is finished. Not "the site is live" — the conditions under which you will agree it is live.
- What must work, listed as things a person can do: "a customer can book and pay for a slot"
- Which browsers or devices are in scope, and which explicitly are not
- What performance or quality bar applies, if any, and how it will be measured
- What you receive at handover: source files, credentials, documentation, deployment access
- Who signs off, and how long they have to do it
Worth noting: Write the out-of-scope list too. It feels unnecessary while you are writing it and settles arguments every single time it exists.
Give a budget range, honestly
The widespread belief that revealing a budget invites overcharging is mostly wrong, and it is expensive. Without a range, freelancers guess, and the responses you receive will span an order of magnitude with no way to compare them. With a range, competent freelancers tell you what is achievable inside it — which is exactly the information you needed.
If a range genuinely cannot be shared, give a shape instead: "smaller than a full rebuild, larger than a weekend fix." Something is better than a blank field that everyone fills in differently.
Be explicit about timeline and why
Deadlines change the price legitimately. A freelancer who must decline other work to meet your date is entitled to charge for that, and one who is told about the date after quoting is entitled to be annoyed. State the deadline and, more usefully, state what it is attached to. "Before the trade show on the 12th" is planning information; "as soon as possible" is noise, and everyone treats it as noise.
Include your examples
Two or three references to things you like, with a sentence explaining what you like about each, communicate more than a page of adjectives. "Clean and modern" means nothing consistent between two people. "Like this site's booking flow, because it asks for payment before the details form" is unambiguous.
The same applies negatively. One example of something you specifically do not want, and why, is unusually valuable and almost nobody supplies it.
A brief you can copy
- What we do, in two sentences, and who our customers are
- The problem we are trying to solve, described as a business outcome
- What exists today, with links and access notes
- What must be true for this to be finished, as a list of things a user can do
- What is explicitly not in scope
- Budget range and preferred pricing structure
- Deadline and what it is attached to
- Two or three references, with reasons
- What we will supply: content, images, access, decisions, and who makes them
- How and how often we expect to communicate
That is roughly one page. It will take an hour to write and it routinely changes the quality of the responses you get more than doubling your budget would.
One last thing: say who decides
Projects stall on approval far more often than on execution. If three people must agree on the design, the freelancer needs to know that before they quote a two-week timeline, because the review cycles — not the work — will set the actual schedule. Naming a single decision-maker, and admitting when there is not one, is the least glamorous and most predictive item in the entire brief.