The Brief Before the Build: How to Ask for Software and Get What You Wanted

There is a particular kind of disappointment that shows up three months into a software project. Everything was delivered. Everything works. Nobody is happy. The client thinks the developer misunderstood; the developer thinks the client changed their mind. Usually neither is true. The brief simply never said the thing that mattered most.

Software rarely fails in the building. It fails in the asking.

Describe the problem, not the solution

The most common mistake in a brief is arriving with the answer already decided. "We need a dashboard with these eight charts." Maybe. But the underlying need might be "our branch managers do not know they are behind until it is too late to fix". That could be a dashboard, or it could be a weekly exception report that emails three people. One of those costs a fortune and gets opened twice. The other gets read every Monday.

A good brief spends most of its length on the current reality: what happens today, who does it, how long it takes, where it goes wrong, and what that costs. Anyone competent can design from that. Nobody can design well from a feature list with no context behind it.

What actually belongs in a brief

• The problem, in business terms. What is slow, risky, expensive or invisible right now, and what it is costing you in time, money or sleep.
• Who uses it, and where. Office staff on desktops behave nothing like drivers on phones in bad signal. This single detail changes the whole shape of a build.
• The process as it really is. Not the official version. The one with the WhatsApp group and the workaround everyone uses because the official version is unworkable.
• What success looks like. A number if possible. "Month-end in two days instead of nine." "No more double bookings." Something you could genuinely check a year later.
• The hard constraints. Budget range, deadline that actually matters, systems it must talk to, rules you cannot break, data that cannot leave the country.
• What is explicitly out. The most useful sentence in any brief starts with "we are not trying to solve".

If your brief could describe five different businesses, it is not a brief. It is a wish. The detail you think is too specific to include is usually the detail that determines the design.

What to leave out

Resist specifying the technology unless you have a real reason. "Must be built in React" or "must use SQL Server" belongs in a brief only when there is an existing environment, a support arrangement or a skills base behind it. Otherwise you are narrowing the field before anyone has understood the problem, and you will pay for that narrowing later.

Equally, resist the temptation to list every feature anyone has ever mentioned. A brief with ninety requirements does not communicate ambition, it communicates that nobody has decided what matters. Rank them, or accept that someone else will rank them for you, probably badly, probably at the point where the budget runs out.

Expect the brief to change, and say so

None of this argues for freezing the specification. The first working version always teaches you things no amount of planning would have. A good brief acknowledges that directly: here is what we know, here is what we are unsure about, here is where we expect to learn. That framing tells whoever is quoting how to structure the work, and it saves everyone the tedious argument about whether a discovery is a change request.

Why this is worth an afternoon

A clear brief gets you comparable quotes, because everyone is pricing the same thing. It gets you a better price, because uncertainty is expensive and you have removed some. It gets you a build that fits, because the person designing it understood what you were actually trying to fix. And it gives you something to point at when the project drifts.

An afternoon spent writing down what you actually need is the cheapest, highest-return hour in the whole project. It is also, reliably, the one everyone skips.