- One to two pages is enough. If your brief runs to twenty, you have written a specification, and probably specified the wrong thing.
- Describe the problem, not the software. "Three people re-key the same order into two systems" is more useful than "we need a dashboard with these nine fields."
- Seven things belong in it: the problem, who is affected, how the work happens today, what a good outcome looks like, what it must connect to, your constraints, and who decides.
- You are not expected to know the solution. Working that out is the job you are hiring for.
- No brief at all is fine too. It just means the understanding gets built in conversation instead, which takes longer.
Search for a software brief template and you will be handed a business requirements document: twenty pages of functional and non-functional requirements, acceptance matrices, and stakeholder sign-off tables. Those are real artefacts and they matter on large programmes with many teams. For a business that needs one workflow fixed, they are the wrong tool, and attempting one usually produces a confident description of a solution nobody has validated yet. What a developer actually needs from you is smaller and harder: a clear account of the problem.
Do you need a formal requirements document?
Almost certainly not. A requirements document specifies what the software must do. That is a useful artefact, but it is an output of the design work rather than an input to it. When it gets written before anyone has studied how the business actually runs, it locks in assumptions that then get quoted, built, and paid for. The most expensive line in any project is a well-built feature nobody needed, and over-specified briefs are one of the main ways that happens.
So write less than you think, and spend the effort on being accurate about the present rather than confident about the future. The longer argument for diagnosing before designing is in what a solution design audit is.
What should a software brief include?
Seven things. Most of them fit in a sentence or two.
| What to include | Why it matters |
|---|---|
| The problem, in business terms | What is going wrong, and what it costs you in hours, errors, or lost work. The single most important paragraph, and the one most briefs skip. |
| Who is affected | How many people, in what roles, and whether they sit at desks or work in the field. Five office users and fifty field users are different systems. |
| How the work happens today | The actual current process, including the spreadsheets and message threads holding it together. Workarounds are evidence, not embarrassment. |
| What a good outcome looks like | How you would know this worked, in plain terms. "The Monday report takes ten minutes instead of a day" is a target anyone can build towards. |
| What it must connect to | Every existing system it has to talk to, named. Integrations drive cost and timeline more than features do, so omitting one changes the whole quote. |
| Constraints | Budget range, any real deadline and why it is real, plus data or regulatory rules you operate under. A budget range gets you a useful proposal rather than a guess. |
| Who decides | One named person who can answer questions and approve work. Nothing slows a project like an unowned decision. |
Notice what is absent: screen designs, field lists, technology preferences, and database structure. If you hold strong views on those, include them as context rather than requirements, and expect a good firm to push back where they conflict with the outcome you described.
The mistake that inflates every quote
The commonest error is arriving with a solution instead of a problem. It sounds like: "We need a mobile app with a live dashboard and role-based logins." That may well turn out to be right, but it has skipped the reasoning, and every firm you send it to will now quote for that app rather than for solving whatever made you want it. You get comparable quotes for possibly the wrong thing.
Describe the problem and you get proposals you can compare on judgement. Describe the solution and you only get proposals you can compare on price.
The fix is a habit rather than a document. For each thing you are about to ask for, write the sentence that explains why. "A live dashboard" becomes "branch managers phone head office for stock figures and get yesterday's numbers." Now a developer can tell you whether a dashboard is the cheapest answer, or whether a nightly report into their inbox would do at a fraction of the cost. That conversation is only possible if the why survives into the brief.
Rather talk it through than write it down?
Book a discovery callHow much detail is enough?
One to two pages, and a rough budget range. People withhold the range because they fear the quote will expand to fill it. The opposite problem is more common: without a range, a firm has to guess which of three very different systems you are asking about, and will either quote for the largest to be safe or the smallest to win, and neither helps you. Saying "we think this is worth somewhere between two and five lakh, tell us if that is unrealistic" gets you a straight answer about what fits, which is what you actually wanted. The mechanics of what moves that number are in how much custom software costs.
Attachments do more than prose here. A screenshot of the spreadsheet you currently live in, an example of the report someone assembles by hand each week, or a photo of the whiteboard where the process is drawn will each tell a developer more than a page of description. Send the messy real thing rather than a tidied version of it.
What if you do not have a brief at all?
Then say so, and book the conversation anyway. Plenty of good projects start with someone describing a frustration out loud for half an hour. A brief is a way of making that conversation shorter and more accurate, not a gate you must pass before you are allowed to have it. What matters is that the understanding gets built before the building starts, and it can be built in a discovery call as easily as in a document. Our own first step is a thirty-minute call built around four questions, set out in how we work.
Where the absence does cost you is in comparing firms. Without a shared written description of the problem, three vendors will each interpret your situation differently, and their quotes become impossible to compare on anything except price. Writing even a single honest page fixes that.
What a good brief actually buys you
Three things, all of them practical. Quotes you can compare, because everyone is answering the same question. A faster start, because the first week is not spent establishing basic facts. And a much better chance of being told that your problem is smaller than you thought, which is the most valuable outcome available and one you will never hear from a firm that only received a feature list. Once you have proposals in hand, the terms that decide whether the project protects you are covered in what should be in a software development contract, and more short answers are in our FAQ. You can also see how these problems looked before we built anything in our case studies.
Question this did not answer? Send it over and you will get a straight answer, not a sales sequence. The good ones become articles.
Leo Tech Labs is a boutique, consulting-led software firm. We start by understanding the problem, then build only what moves it. See our solution design work.