A brief has one job that most people miss. It is not to describe the software. It is to give several different suppliers enough shared information that their quotes can be compared to each other.
That distinction changes what goes in it. A document describing what you want in detail produces quotes for that description, including its mistakes. A document describing the problem, the constraints and how you will judge success produces quotes for solving your problem, and the differences between them tell you something useful about each supplier's judgement.
This is a practical guide to writing the second kind. It assumes you have already worked out the underlying answers; if you have not, what to work out before you ask anyone to build software covers that part.
How long it should be
Two to four pages. Not thirty.
Long briefs feel thorough and behave badly. Every extra page adds specification that has not been tested against a developer's questions, and specification that has not been tested is where wrong assumptions hide. A thirty-page brief also filters out exactly the suppliers you want: the ones with enough work to be selective read the first two pages, notice that the document has decided everything, and price it as a build-to-spec job with a large margin for the parts that turn out to be wrong.
Four pages, answered honestly, is enough for a competent supplier to ask you the right six questions. Those questions are the point.
What goes in it
Eight sections. Each answers something a supplier needs in order to price the work rather than guess at it.
| Section | What it answers | What happens if you leave it out |
|---|---|---|
| The business, in a paragraph | What you sell, to whom, and roughly how big the operation is | Everything gets priced for a generic company, usually a larger one than yours |
| The problem | What is wrong today, in terms of the work rather than the software | The supplier prices the thing you named instead of the problem you have |
| Who will use it | Roles, numbers, and how often each one touches it | User numbers and permission complexity are two of the largest cost drivers, so both get guessed |
| How the work runs now | One case traced end to end | The estimate excludes the parts of the process nobody described, which are the parts that surprise everyone |
| What success looks like | A checkable statement, judged a year later | No shared definition of done, which is the single most common cause of a disputed final invoice |
| Existing systems | What you run, what stays, what must be connected | Integration work is discovered mid-project and becomes a change request |
| Constraints | Budget range, real deadlines, systems you are stuck with, who maintains it | The proposal is shaped around assumptions rather than your situation |
| Process | How you will decide, who decides, when you need it by | Suppliers cannot tell whether they are one of two or one of fifteen, and price accordingly |
Two of those deserve expanding, because they are the ones most often written badly.
The problem section
Write it in terms of work, not software. Three or four paragraphs, describing what happens today and why it is a problem, with something quantified wherever you can quantify it honestly. Volumes are the most useful numbers you have: how many orders a week, how many customers, how many people doing this job, how long it takes now.
Resist the urge to explain the solution here. If you already have a strong view, put it in its own short section headed what we think the answer might be, clearly separated. That way a supplier can tell you it is the wrong answer without appearing to argue with the brief itself, which is a distinction that matters more than it should.
The constraints section
State a budget range. This is the point people most often ignore. The reasoning against it, that suppliers will price up to whatever you name, is weaker than it looks. A supplier who does not know your ceiling has three choices: propose the fullest version and lose on price, guess low and discover the shortfall in month three, or refuse to quote. None of those helps you.
A range does something more useful than filtering. It changes the question from "how much will this cost" to "what is the best version of this that fits", which is a question a good supplier can answer well and a poor one cannot answer at all. The answers you get back are the most informative part of the whole exercise.
What to leave out
A feature list presented as requirements. By all means include the things you know you need. Label them as such, and leave room for the reply that three of them are unnecessary and two more are missing.
Screen designs. If you have sketched something, include it as an appendix marked illustrative. Sketches inside the main brief get read as decisions.
A technology choice, unless it is a genuine constraint. "Must be PHP because our IT team maintains PHP" is a constraint and belongs in the brief. "Should use React" without a reason attached is a preference picked up somewhere, and it will either be silently ignored or expensively obeyed.
Confidential detail you do not need to share. A brief goes to several companies you have not yet chosen. Describe the process, not the trade secrets inside it, and do not attach real customer data.
Boilerplate. Mission statements, values, a paragraph about how the market is changing. Nobody pricing the work reads it, and it makes the document longer without making it clearer.
Writing it when you do not know the answer
Most briefs contain guesses presented as facts, because the writer felt that admitting uncertainty would look unprofessional. It has the opposite effect.
Write unknown, or to be decided, or we have two views on this internally. Then add one line about how it might be resolved. A supplier reading "we do not yet know whether customers should see each other's pricing — this needs a decision from the commercial team" learns two things: where the risk is, and that you are the sort of client who says so. Both make the quote more accurate.
The same applies to the parts you suspect will be contentious. If you know the warehouse manager disagrees with the whole idea, say so. It is going to affect the project either way, and it is cheaper to design around a known objection than to discover it during a launch.
Sending it out, and reading what comes back
Three suppliers is a sensible number. Five is a lot of your time and produces diminishing information; one gives you nothing to compare against.
Give everyone the same document and the same window. When one asks a good question, send the answer to all of them — partly for fairness, mostly because otherwise the quotes stop being comparable, which was the point of the exercise.
When the responses arrive, most of the useful information is not in the price.
- What did they ask? The best signal available. A supplier who came back with six sharp questions about your process has understood something. One who quoted immediately from the document has priced their reading of it, and their reading has not been checked.
- Did anyone tell you something you did not want to hear? That the project should be smaller, staged differently, or that an off-the-shelf product would do most of it. That answer costs a supplier money to give, which is why it is worth paying attention to.
- Do the quotes describe the same thing? If they differ by a large multiple, they usually are not comparable at all. Ask each to state what they have assumed. The assumptions are where the difference lives.
- What is excluded? Hosting, third-party licences, content, data migration, training, support after launch. A cheap quote with four of those missing is not cheap.
An illustrative example
A service business with 30 staff wants to replace a scheduling spreadsheet. Two versions of the same brief:
Version one. We need a scheduling system with a calendar view, drag and drop, SMS notifications, a mobile app for engineers, a customer booking page, and reporting. Six features, no context. Every supplier prices six features, the quotes vary by the hourly rate and the assumed depth of each one, and none of them can tell you whether the engineer app is worth building.
Version two. We schedule about 200 jobs a week across 18 engineers, in a shared spreadsheet. Two coordinators maintain it, and it breaks when both edit at once. Engineers phone in for their next job, which is roughly 60 calls a day. Customers cannot see when we are coming, so we get "where are you" calls all morning. If this works, coordinators stop rekeying and the "where are you" calls stop.
The second version is shorter and produces better quotes, because it makes the cost drivers visible: 18 engineers, two coordinators, 200 jobs a week, two named categories of interruption. It also lets a supplier point out that the engineer app and the customer page solve different problems and could be staged a year apart. The example is hypothetical, but the difference between the two documents is not.
Common questions
Should the brief include a deadline? Include real dates and their reasons. A date driven by a contract, a season or a system being retired is a design constraint. A date chosen because it would be nice has the effect of a constraint without the benefit, and it distorts everything downstream.
What if suppliers refuse to quote from a brief this short? Some will want a paid discovery stage before committing to a number, and that is a reasonable position rather than an evasion — it is difficult to price complex work honestly without examining it. What matters is that the discovery has a fixed fee, a defined output, and no obligation to continue with the same supplier afterwards.
Can I reuse a template I found? As a checklist, yes. As a document, no. Templates are written for the general case and encourage you to fill sections that do not apply to you, which pads the brief with material that is not true of your business.
Who should write it? Whoever understands the process best, reviewed by whoever controls the budget. The common failure is the reverse: written by the budget holder, reviewed by nobody who does the work.
The short version
- The brief exists to make quotes comparable, not to describe the software.
- Two to four pages. Longer briefs get worse quotes from fewer good suppliers.
- Eight sections: the business, the problem, users, how the work runs now, success, existing systems, constraints, process.
- State a budget range. Withholding it produces guesses, not savings.
- Leave out feature lists presented as requirements, screen designs, technology preferences without reasons, and boilerplate.
- Write unknown where you do not know. A stated unknown is information; a papered-over one is a change request later.
- Judge the responses on the questions they asked, what they excluded, and whether anyone was willing to tell you the project should be smaller.
Where to take this next
The brief will produce a range of numbers, and the next useful thing is understanding why they vary so much. That is a subject of its own, and it is the one most likely to save you money.
If you would rather start with a conversation than a document, that also works. A paragraph is enough to begin with — discuss your idea, or if it is easier, say hi on WhatsApp.
# Visual recommendations
Concepts only. Hairline drawing, ink and brass.
Hero visual — two briefs, two sets of quotes
Concept. Two columns side by side. Left: a document icon labelled feature list, with three quote figures below it drawn as bars of wildly different heights, and a question mark between them. Right: a document labelled problem, users, volumes, constraints, with three bars of similar height and a small tick between them. No currency, no numbers on the bars — the point is variance, not amount.
Purpose. States the article's premise before the reader starts: the brief's quality shows up as the comparability of what comes back.
Alt text. A feature-list brief produces three quotes of wildly different sizes that cannot be compared. A brief describing the problem, users and constraints produces three comparable quotes.
Supporting visual — the eight sections
Concept. A single-page layout diagram: eight stacked hairline bands on a page outline, each labelled with its section name and sized roughly in proportion to how much space it should take. The problem and constraints bands are visibly the largest; what we think the answer might be is a small band drawn with a dashed border to show it is optional and separate.
Purpose. Gives the reader a shape to copy. The proportions carry advice that the table cannot.
Placement. At the head of the "What goes in it" section, above the table.
Alt text. A two-to-four page brief with eight sections, where the problem and constraints sections take the most space and a separate optional section holds your own view of the answer.