Writing a software brief that gets you a real quote
A two-line email gets five guesses. A one-page brief gets comparable quotes and a smaller first version. The eight sections, in order, with what each prevents.
The short answer
Suppliers estimate what they can picture. A two-line email lets each of them picture a different system, and the quotes come back three times apart. A one-page brief lets them all picture the same one, and the quotes become comparable, the smallest useful version becomes visible, and the scoping calls that usually take weeks are replaced by a few questions.
The brief is not a feature list. It is eight short sections about the problem, the people and the process.
The eight sections
| Section | What to write | What it prevents |
|---|---|---|
| 1. The problem | What hurts today, in one paragraph, with a measurable cost if you have one | Building something nobody needed |
| 2. The people | Who will use it, how many, how often, on what devices, how technical | Wrong assumptions about roles and screens |
| 3. The current process | Step by step, as it happens today, including the exceptions and what people do then | The expensive surprises found during development |
| 4. What it must let people do | Needs, not features: “a client can see their order status without calling” | Locking in the first solution that came to mind |
| 5. The systems involved | Every tool it must talk to, in which direction, how often | Integration effort missing from the estimate |
| 6. Constraints | Data rules, compliance, deadlines, budget range, must-haves and must-nots | Proposals that ignore the boundary |
| 7. The smallest useful version | The one thing that, if it worked, would already help | Quotes for the whole vision when you needed a first step |
| 8. What success looks like | How you will know it worked, in numbers | A project with no finish line |
The section that matters most
Section three, the current process, is what suppliers most need and most rarely get. Write it as it actually happens: who does what, in what tool, in what order, and what happens when the customer changes their mind, the payment fails, the document is missing. The exceptions are where the real complexity lives, and a brief that names them gets an estimate that includes them.
How to use it
- Write it in an afternoon. With the people who do the work today, not only managers.
- Send the same brief to every supplier. Comparable inputs, comparable quotes.
- Ask for the smallest useful version to be priced first. Section seven is there for that.
- Ask each supplier what is unclear. Their questions reveal both the gaps in the brief and how carefully they read it.
- Keep the brief. It becomes the first page of the scope, and the document you check the finished software against.
What this means for you
Before you ask for a quote, spend an afternoon on the eight sections. You will get quotes that can be compared, a smaller first version than you expected, and a supplier conversation that starts with their questions instead of your explanations. The brief is the cheapest part of the project and the one that decides how the rest goes.
Frequently asked questions
Should the brief list all the features we want?
List what the software must let people do, not screens and buttons. 'A client can see the status of their order without calling us' is a need; 'a dashboard with a status widget' is a solution. Suppliers propose better solutions when they know the need, and feature lists lock in the first idea.
We do not know what is technically possible. How can we write a brief?
You do not need to. Describe the problem, the people, the process and the constraints. Technical possibility is the supplier's job. A brief that admits what you do not know gets a better response than one that guesses at technology.
How detailed should the process description be?
Step by step, as it happens today, including where it goes wrong and what people do then. Two or three exceptions are usually where most of the complexity, and most of the cost, sits. If the process cannot be written down, that is the first finding, and the first task.