How to write a good software brief
A vague brief gets a vague quote. A good one costs you an hour to write and saves weeks of back-and-forth later.
· 2 min read · For anyone about to commission software
Most software briefs we receive describe the destination — “we want an app like X” — without describing the actual problem. That gets you a quote, but often not the right one, because the vendor is guessing at details that change the cost significantly. An hour spent writing a proper brief usually saves weeks of revisions later.
What a good brief includes
- Who uses this, and what they are doing right now instead — paper, Excel, WhatsApp, another app.
- The one or two things that must work well on day one, separate from things that would be nice eventually.
- Real numbers — how many users, how many records, how many transactions a day — not “a lot” or “not much”.
- Anything it must connect to — an existing accounting system, a government database, a payment method.
- Any hard deadline, and why it is hard.
What to leave out at this stage
You do not need to specify the technology, the screen designs, or the database structure — that is the vendor's job to propose, not yours to guess. A brief full of technical requirements you are not sure about often does more harm than good, because it locks in choices before anyone has properly looked at the actual problem, and those early choices are the hardest ones to undo later.
A short example
Compare “we want an attendance app” with: “40 classes, teachers currently use a paper register, attendance must be marked in under a minute per class even with a weak internet connection, and parents should get a message the same day if their child is absent.” The second version gets you a quote that means something.
Questions any vendor should ask you back
- What happens today, without this software — the manual process it replaces?
- What is the one failure that would make this not worth using?
- Who signs off that it is ready to go live?
- What is the budget range, even roughly — it changes what gets proposed?
How we can help
We start every engagement by turning a brief like this into a clickable first version, so you can see and react to the actual screens before real development begins — not after. See how we work, or talk to us with even a rough brief; we will help sharpen it.
