Why Most Briefs Fail
The briefs that go wrong almost all make the same mistake: they describe a solution instead of a problem. "We need an app with a dashboard, user logins, and reports" tells a developer nothing about what the business actually needs — so every company quoting against it prices a different imaginary product, and the quotes come back unusable.
The fix is simple: describe your world, not the software. The developer's job is to work out what to build; your job is to make sure they understand what it's for.
What to Include
1. The problem, in operational terms
What takes too long, goes wrong, or can't grow? Be concrete: "Every Monday someone spends four hours retyping weekend job sheets into the invoicing spreadsheet" is a brief a developer can price. "We want to digitise our processes" is not.
2. The workflow, end to end
Walk through the process as it happens today — including the workarounds, the spreadsheet nobody admits to, and the steps that only live in one person's head. The workarounds are usually where the value is.
3. Who uses it
List the kinds of people who'd touch the system: office staff, field crews, customers, managers. For each, note where they are (desk, van, home) and what they need to do. This single list drives more of the cost than almost anything else.
4. What it must talk to
Name the systems that stay: accounting package, payroll, payment provider, industry platforms. Note which ones the new software must read from or write to.
5. The constraints
Real deadlines (seasonal launch? contract renewal?), compliance requirements (CQC, GDPR, industry rules), and — yes — your budget range. Developers can design to a budget, but only if they know it. Withholding it doesn't get you a better price; it gets you a proposal for the wrong-sized thing. Our cost guide will help you set a realistic range.
6. What success looks like
Finish with one or two measurable outcomes: "results entry takes minutes, not hours", "no more paper job sheets", "one source of truth for staff records". This becomes the yardstick every design decision gets measured against.
What to Leave Out
- Technology choices. Unless you have a genuine constraint (an existing system, an in-house team), let the developer recommend the stack — and expect them to justify it in plain English.
- The exhaustive feature list. Ten stakeholders' wishlists produce a bloated spec. Bring the problems; prioritise features together later.
- Screen designs. Sketches of how you imagine it are useful context, but presenting them as requirements locks in your first guess before anyone's explored better options.
A Template You Can Copy
One page covering these headings is a genuinely excellent brief:
- About us: what the business does, team size, how you work
- The problem: what hurts, how often, and what it costs you
- Today's process: the workflow as it really happens
- Who's involved: user types and where they work
- Must connect to: systems that are staying
- Constraints: deadline, compliance, budget range
- Success means: one or two measurable outcomes
What Happens Next
A good developer takes your brief into a discovery conversation — asking the questions the brief raises, watching the workflow if possible, and turning it into a written specification you can read and challenge. Only then should anyone put a fixed number on it. That's how we work: specification first, fixed quote second, milestones after that.
Brief-Writing FAQs
How long should a software brief be?
One page is plenty; two is the ceiling. Past that, you're writing the specification — which is the developer's job, done properly during discovery with your input.
What if we don't really know what we need?
Then say exactly that, and describe the pain instead. "We're drowning in spreadsheets and don't know what the fix looks like" is an honest, workable brief — discovery exists precisely for this situation.
Should we send the same brief to several companies?
Yes — an identical brief is the only way to compare quotes fairly. Be suspicious of any company that quotes a firm price without asking you a single follow-up question.