How to write a development brief that gets you a range instead of «it depends»

The most useful brief I ever read was seven lines long. The most useless one ran to four pages, with a company mission statement and an audience breakdown by age. We estimated the first one the same day. The second one cost us a week of clarifying questions.

Length had nothing to do with it. Five specific things were missing from the long version, and that was the whole difference.

Describe the problem, not the format

«We need a website» names a format. A problem sounds different. We lose enquiries because they arrive in three separate messengers and some go unanswered. Or: we want to sell to our own customer base without paying an aggregator.

A format implies markup (and an argument about shades of green). A problem implies everything else, including what can be skipped. For a company handling water use permits the problem was collecting enquiries in one place, which is why the project ended up with a rental calculator, two forms and automatic delivery of enquiries into a spreadsheet and to managers in Telegram. Half of what usually gets drawn on such sites never appeared at all.

Give one person’s path instead of a feature list

Feature lists look useful and estimate badly. «A personal account» covers a page with order history, a role based permission system and report exports, and those differ several times over in effort. Describe one person’s path step by step: where they came from, what they saw, what they clicked, how it ended. From that a vendor assembles the feature list themselves, and you get to see their version of it. That matters more than it sounds, because any gap in understanding shows up on the first call, long before acceptance.

List the external systems

This is the item that moves the estimate most. Write down what the product must exchange data with: accounting system, point of sale, CRM, payment provider, stock levels, delivery. A wholesale flower supplier’s storefront had four such systems, and each turned out to be a separate task with its own timeline. If there are no integrations at all, say so too. It moves the estimate down. We hear that as good news.

Name the deadline and the reason behind it

What helps is the reason behind the date. Does «as soon as possible» help? Never. «We open the office on 15 October» or «our season starts in March» immediately decides what we cut to make it and what waits until later.

If the deadline is hard, say so at once. Then the conversation is about which part of the product must work by that date. Nobody wastes time trying to fit everything into it, and you get a plan instead of a promise.

Name a budget frame

The most awkward line in a brief and the one that saves the most time. A stated frame removes half the conversation because it eliminates options that do not fit you. Honesty runs both ways here. If the budget is a hundred thousand and the task costs four hundred, it is better to learn that on day one. In that case we say plainly that the task cannot be done for this money, and show which part of it can. Sometimes the client walks away after that, which is a perfectly good outcome, better than three weeks of talks ending in a refusal anyway.

What a brief does not need

A technical specification. If you have no developer in house, the vendor writes it, and that is separate paid work. A specification written by a non technical person usually takes longer to unpick than the original problem does. A stack chosen on our behalf is the second thing we do not need. «Build it on this CMS» is occasionally justified and more often a retelling of somebody else’s advice that narrows the solution for no reason. And do not hide that another vendor came before us: knowing what exists and where it stopped saves weeks, because «rewrite from scratch» and «pick up mid flight» are different estimates and different money.

Copy this template

Company: what we do.
Problem: what does not work today, in measurable form.
Scenario: the user path, step by step.
External systems: what we need to exchange data with.
What already exists: design, copy, domain, previous vendor.
Deadline: date and reason.
Budget: a frame, or «waiting for your estimate».
Contact: name, Telegram or email.

That is enough for a range and a list of assumptions on the first call. Seven lines.

We never counted how many projects failed specifically because of a weak brief. The link between the quality of a description and how the project ended is something I see by feel. Feel is poor evidence.

There is a flip side agencies rarely mention. A brief shows the task and, on top of that, what the project will be like. When the answer to «what is the problem» describes an interface, and it later turns out four people sign off and disagree with each other, the brief is no longer the issue. That is exactly the information we read it for, and sometimes it means we should decline. If your own brief is stuck, send it to us and say which line you cannot fill in.