A good software brief is one or two pages that say who will use the thing, what job it does for them, what it must connect to, what's out of scope and how you'll know it worked. Write it before anyone designs a screen, because every gap you leave gets filled by someone else's guess.
Most rewrites I've seen didn't start with bad developers. They started with a brief that described screens instead of the job, or no brief at all. So this is how to write a software brief that a builder can work from, with a free template at the end you can copy.
What a useful brief actually is
A brief isn't a specification, and it isn't a wish list. It's a short, plain description of a problem worth solving and the limits of the solution. A builder should be able to read it in ten minutes and ask sharp questions.
The GOV.UK Service Manual puts this well for government services: start by learning about the people who'll use it, because if you don't understand who they are or what they need, you can't build the right thing. The same goes for a five-person firm. "We need a client portal" is a solution. "Clients email us three times a week asking where their job is, and answering takes a negotiator off the phones" is a need, and it's the need a builder can work with.
Over five years of business analysis, the briefs that worked were rarely the longest. They were the ones where the owner had watched the work being done and written down what they saw.
The minimum sections that save rewrites
These five sections stop most of the arguments that cause rewrites later:
- Users and jobs. Who will use it, and what are they trying to get done? Name roles, not people, and list the three or four jobs that matter most.
- Current pain. What happens today, step by step, and where does it go wrong? Include the workarounds, the spreadsheets and the "ask Sarah" moments.
- Must connect to. Which tools does it need to read from or write to? Say which system owns each piece of data.
- Out of scope. What it won't do, at least in the first version. This is the section people skip, and it's the one that saves the most money.
- Success signal. How will you know it's working? Pick something you can see, like "nobody re-keys a booking" or "every completed job has an invoice by Friday".
Picture a small accountancy practice that wants a client upload area. Without an out-of-scope line, the build quietly grows to include e-signatures, payments and a chat feature. With one ("version one only collects documents against the records checklist and tells the accountant they've arrived"), it ships, and the extras get judged on how the first version is actually used.
Decisions to make before design
Some decisions shape the whole build, so make them before anyone opens a design tool:
Who owns the data? Decide which system is the source of truth for customers, jobs and money. If you skip this, you'll end up with the problem described in the real cost of disconnected tools.
Who signs off? Name one person who can say yes to a design and no to a new feature. Committees produce slow, bloated software.
What personal data is involved? If the software handles customer or staff information, UK GDPR expects you to build data protection in from the start, not bolt it on later. The ICO calls this data protection by design and by default. In practice, list what personal data you need, who can see it and how long you keep it.
Buy, configure or build? Check honestly whether an off-the-shelf tool does most of the job. Custom software makes sense when the job is central to how you work and nothing on the market fits without painful workarounds.
A software brief template you can copy
Copy this into a document and fill it in. Keep each answer short. If a section runs past half a page, it's probably two projects.
SOFTWARE BRIEF
Project name:
Brief owner (signs off):
Date and version:
1. Users and jobs
Who uses it (roles):
The 3-4 jobs they need to get done:
2. Current pain
How it works today, step by step:
Where it goes wrong, and how often:
Workarounds in use (spreadsheets, inboxes, people):
3. Must connect to
Tools it reads from:
Tools it writes to:
Source of truth for customers / jobs / money:
4. Out of scope (version one)
It will not:
5. Success signal
We'll know it works when:
Decisions
Personal data involved, who can see it, how long we keep it:
Buy, configure or build, and why:
Budget range and deadline (if fixed):
Open questions:Turn the brief into a build
Once the brief is written, walk through it with whoever will build it. A good builder will challenge parts of it, especially the scope, and that conversation is worth more than another week of polishing the document.
Then build the smallest version that hits the success signal, put it in front of the people in "users and jobs", and update the brief with what you learn. If the pain you're describing is a spreadsheet that's grown too important, start with when to replace spreadsheets with software. If it's mostly admin between tools, what to automate first may be a cheaper starting point. Turning briefs like this into working tools is what we do with Web apps, and you'll find more on the build-or-buy question in our guides.
Questions people ask
What's the simplest way to learn how to write a software brief if I'm not technical?
Describe the work, not the technology. Write down who does the job, what they do step by step, where it goes wrong and what "fixed" would look like. A good builder will translate that into screens and data.
How long should a software brief be?
One or two pages for most small-business projects. If it's longer, you're probably writing a specification or describing more than one project.
What's the most common mistake in a software brief?
Leaving out what's out of scope. Without it, every good idea joins the first version, and the build gets slower and more expensive.
Do I need a brief if I'm buying off-the-shelf software?
Yes. The same five sections help you compare products against your actual jobs rather than their feature lists.
Sources
- Learning about users and their needs (GOV.UK Service Manual)
- Data protection by design and by default (Information Commissioner's Office)