Short answer
A good software brief describes the problem, the people affected and what success looks like in numbers — not a solution. Include the current process as actually performed, what is explicitly out of scope, your must-haves versus nice-to-haves, constraints, and who can make decisions. Vague briefs produce padded quotes.
Describe the problem, not your solution
The most common briefing error is arriving with a solution already chosen: "we need a dashboard with these six screens". That fixes the answer before anyone has examined the question, and it hides the actual problem from the one group of people paid to solve it.
Describe what goes wrong today instead. What takes too long, what gets re-keyed, what nobody can find out without asking three people, what the business cannot do that it needs to. A supplier worth hiring will frequently propose something simpler than what you had in mind.
Document the process as it actually happens
Write down how the work is really performed, including the workarounds, the private spreadsheets and the exceptions that "hardly ever happen". Those exceptions are where software projects overrun, because they were invisible at quoting time and turn out to be a third of the real complexity.
It helps enormously to walk a supplier through the current process on a screen share rather than describing it. Ten minutes of watching someone actually do the job reveals more than a ten-page document.
Define what is out of scope
Stating what you are not asking for is as valuable as stating what you are. It prevents padded quotes, because a supplier who cannot see the boundary prices for the worst case.
Be explicit about integrations especially. "It should work with our accounts system" is the single most expensive sentence in most briefs, because it can mean a nightly file export or a real-time bidirectional sync, and those differ by an order of magnitude.
Separate must-have from nice-to-have
Rank the requirements honestly. If everything is essential, nothing is, and the first schedule pressure will force someone else to decide your priorities for you.
A useful test: which features, if missing at launch, would stop you using the system at all? That is your must-have list. Everything else can follow in a later phase, and saying so up front usually gets you a cheaper, faster first release.
State constraints and decision-making up front
Include the real budget range. Suppliers are not trying to spend it all; they are trying to work out whether to propose a bespoke build or a configured product, and those are different conversations. Withholding the number wastes both sides' time.
Include hard deadlines and why they are hard, the systems that must be worked with, any regulatory constraints, and who has authority to make decisions. A project with no empowered decision-maker on the client side will stall regardless of how good the supplier is.
Say how success will be measured
Put a number on it: order processing time reduced from two days to two hours, month-end reporting from three days to one, manual re-keying eliminated for a named process.
It focuses the design on what matters, gives you a way to judge whether the money was well spent, and stops the project being assessed on whether it feels nice — which is how expensive software gets built and quietly abandoned.
Key points
- Describe the problem and the current process, not the solution you have imagined.
- Document exceptions and workarounds — they are where overruns come from.
- Say what is out of scope; vague boundaries produce padded quotes.
- Rank must-have against nice-to-have, and give a real budget range.
- Define success in numbers before the build starts.
Frequently asked
Should I tell suppliers my budget?
Yes. It determines whether they propose a bespoke build or a configured product. Withholding it produces quotes aimed at the wrong solution.
How detailed does a brief need to be?
Detailed on the problem and current process; deliberately open on the solution. Two or three well-written pages plus a screen-share walkthrough beats a thirty-page specification of a solution.
What if we do not know what we need?
Say so and pay for a short discovery phase. It is far cheaper than a fixed-price build against requirements that turn out to be wrong.
Written by the Softech Team team. Last reviewed September 2026. This guide is general information, not advice for your specific circumstances.