How to Write a Brief for a Software Project
The document that decides the quality of every quote you get
The brief is the cheapest part of a software project and the one that determines most of what follows. A good one gets you comparable quotes, sensible questions and a realistic timeline. A vague one gets you three numbers that cannot be compared, because each supplier has guessed at something different.
You do not need a specification. You need enough that somebody who has never seen your business can understand what the work is.
Start with the problem, not the solution
The most common mistake is writing a list of screens. It feels like progress and it removes the supplier’s ability to help, because they will price what you described rather than what you need.
Instead of “a dashboard showing outstanding jobs”, write “supervisors cannot tell which jobs are running late without ringing round, which takes about an hour every morning”. The first sentence gets you a dashboard. The second might get you something better, and it tells the supplier what success would look like.
What to include
1. What the business does, briefly
Two or three sentences. Enough context that the rest makes sense.
2. The problem you are solving
Be specific. Who is affected, how often, and what it costs. “Finance spend two days a month reconciling the delivery log against invoices” is worth more than “our processes are inefficient”.
3. How the process works today
The single most valuable section, and the one most often missing. Walk through it step by step, including:
- Who does each step
- What system or file each step happens in
- What triggers the next step
- What happens when something goes wrong
Include the exceptions. Every business has a process that runs one way except for one client, or one product line, or at year end. Those exceptions are where estimates go wrong, so naming them early is entirely in your interest.
4. What you want to be true afterwards
Outcomes, not features. “A supervisor can see late jobs without asking anyone.” “Nobody rekeys an invoice.” “We can prove who approved a discount.”
5. Who uses it
Roles, rough numbers, and what each role should and should not see. Whether anybody outside the company needs access, because that changes the shape of the work considerably.
6. What it has to connect to
List every system involved, even ones you think are irrelevant. For each, say whether it has an API, whether anyone internally administers it, and who would grant access. This section is the most common source of delay, so detail here pays for itself.
7. What the data looks like
Roughly how many records, where they live now, and what state they are in. If the existing data is messy, say so. Everyone’s is, and a supplier who knows can plan for it.
8. Constraints
Deadlines and why they exist. Budget range, if you have one. Any regulatory requirement, any policy about where data may be held, anything already decided that is not up for discussion.
9. What is explicitly out of scope
A short list of things you are deliberately not asking for. This is the section that keeps quotes comparable, and it saves suppliers guessing generously.
10. How you will decide
Who is involved, roughly when, and what matters most to you. Suppliers respond better to a clear process than to a long wait.
On budget
There is a common instinct to withhold a budget in case suppliers price up to it. In practice, withholding it produces quotes that are not comparable and cannot be acted on, because each supplier has assumed a different scale of project.
A range works well. It lets a supplier tell you what is achievable within it, or say honestly that it is not enough, which is information you want before spending time on proposals rather than after. If you have no idea what the range should be, what custom software costs in the UK sets out what moves the number.
Mistakes that produce vague quotes
Describing the solution. You get what you described, priced as described.
Leaving out the exceptions. They surface during the build and become change requests.
No named decision-maker. Suppliers price in the delay.
“And anything else you think we need.” An open-ended invitation is priced cautiously, which means expensively.
No mention of existing systems. The largest single source of estimate error.
Asking for everything at once. A brief covering eight processes gets a number covering eight processes. Ask for the first one and a direction of travel instead, which is also the fastest way to get something live, as we cover in how long custom software takes.
How long the brief should be
Two to four pages is usually right. Long enough to include the process walkthrough and the systems list, short enough that somebody reads all of it.
If it is running longer, that is often a sign the scope is too large for a first piece of work rather than a sign the document needs editing.
What good looks like from the other side
A supplier reading a good brief should be able to ask sharp questions rather than general ones. If the questions coming back are “what are you trying to achieve”, the brief has not done its job. If they are “what happens to a job that is cancelled after dispatch”, it has.
Those questions are also the best early signal about the supplier, which is worth paying attention to when you are choosing between them. We have set out what else to look for in choosing a software development partner.
A shortcut worth taking
If a spreadsheet currently runs the process, it is most of your brief already. It encodes the real rules, including the exceptions people forget to mention. Print it, annotate what each tab and column is for, and attach it. That single document tells a supplier more than several pages of prose, and it is the reason spreadsheet replacements are often the most accurately quoted projects of all.