We read a lot of briefs. Some arrive as a two-page document, some as a spreadsheet of four hundred requirements, one memorably as a voice note recorded while driving. The length has almost no bearing on quality. What separates a good brief from a bad one is whether it makes disagreement possible.
That’s the actual job. A brief is not a specification and it isn’t a wish list — it’s the document that lets someone with experience tell you that a third of your plan is unnecessary, or that your deadline and your feature list are describing two different projects. If it doesn’t create room for that conversation, it will get you quotes that are polite, similar-looking, and wrong.
Why most briefs produce useless quotes
Send ten agencies a feature list and you’ll get ten numbers back. They will differ by a factor of three, and you will have no way to tell why.
The reason is that a feature list transfers no judgement. “User accounts” is somewhere between three days and three months depending on questions the brief never asked: single sign-on or email and password, one organisation per user or several, does an admin need to impersonate someone to debug a support ticket. Each responder silently assumes an answer, prices their own assumption, and never shows you the working. The cheapest quote is usually just the one that assumed least.
So the goal isn’t to specify more. It’s to give everyone the same constraints and the same definition of success, then let them show you how they’d think about it.
The seven things worth writing down
The problem, not the solution. Start with what’s broken and who feels it. “Our ops team rekeys every order into three systems by hand, roughly four minutes per order, and it breaks past about fifty orders a day” is worth more than any number of screen descriptions. It tells a reader what the software is for, which is the only basis on which they can suggest something better than what you had in mind.
Who it’s for, honestly. How technical are they? What device is in their hand? Are they at a desk, or on a warehouse floor wearing gloves, or on a train with two bars of signal? This one section quietly determines half the technical architecture, and it’s the one most briefs reduce to “users”.
What it must do. The handful of things that have to work for the thing to be worth shipping at all. Five bullets is usually right. If you have twenty and they’re all essential, the prioritising hasn’t happened yet — and if you don’t do it, a developer will do it for you by accident, in the order the tickets happened to be sorted.
What it must not do — yet. This is the section almost everyone omits and the one that saves projects. Writing down what you are deliberately not building this time is what stops a three-month build becoming a nine-month one. It also gives everyone, including you, permission to say no in month two without it feeling like a defeat. If you write nothing else well, write this.
What success looks like. Ideally a number: a time that drops, an error rate that falls, a conversion that rises. “Users love it” cannot be built toward and cannot be argued with. A measurable target lets an engineer make a hundred small trade-offs in your favour without stopping to ask you about each one.
Constraints. The real deadline and what’s attached to it, a rough budget band, the systems it has to talk to, compliance or data-residency requirements, anything you’re already committed to. Constraints feel like bad news to share and they are the opposite — they’re what makes an estimate real rather than decorative. A team that knows the deadline has a board meeting behind it will scope differently, and better.
What you don’t know. List your open questions. Native app or web? How real-time does the sync actually need to be? Admitting uncertainty is a strength in a brief: it tells the reader exactly where their experience is most valuable, and it stops them quietly assuming an answer you never gave.
What to leave out
The technology. If you don’t know, don’t guess. Choosing the stack is the job of whoever you hire, and a brief that specifies React Native or Postgres without a reason anchors everyone to a decision made by the least informed party in the conversation. If you do have a real constraint — an existing team, an existing database — that belongs under constraints, with the reason attached.
Detailed screen designs, unless you have them and they’re good. A brief full of wireframes tends to get priced as “build these screens”, which suppresses exactly the suggestion you most want to hear: that four of them could be one.
Padding. Nobody has ever won a better quote through page count. Two pages that answer the hard questions beat twenty that restate the obvious.
How to tell a good response from a bad one
This is the part people don’t expect: the brief’s real output isn’t the quotes, it’s how the responses differ.
A good response disagrees with something. It asks two or three questions that make you think. It tells you which part carries the most risk, and it may well suggest cutting something you were attached to. Occasionally the best response is “this is not the right project for us, and here’s why” — which is genuinely more useful than an enthusiastic yes from someone who hasn’t read carefully.
A weak response restates your brief in nicer language, prices every feature at similar granularity, and asks nothing. That’s a team preparing to build precisely what you asked for, which sounds like what you want and is how projects end up technically complete and commercially pointless.
The thing worth remembering
You’re not writing a legal document and you’re not trying to eliminate uncertainty. You’re trying to make the uncertainty visible, so that the people bidding have to show you how they’d handle it.
A brief that says “here is the problem, here is what winning looks like, here is what we’re not doing, and here are the three things I’m unsure about” will get you sharper thinking than any specification, from every team you send it to. Including the ones you don’t hire.
If it helps, we’ve put the version we scope from on the site: a guided brief template with the seven sections above, which builds a document as you fill it in. Copy it, download it, take it to whoever you like — the point of a good brief is that it makes every quote you receive comparable, and that works in your favour whoever ends up building the thing.