← Journal· Guides · Jul 24, 2026 · 4 min read

How to write a software brief that gets you a real quote

We read a lot of software briefs. The ones that earn a fast, honest quote share very little with the long ones. Here is what actually goes in a good brief.

We read a lot of software briefs, and the ones that earn a fast, honest quote have almost nothing in common with the long ones. A brief is not a spec. It is a way to tell a builder what you are trying to change and how you will know it worked. Most briefs skip that and jump straight to a feature list, which is exactly why the quotes that come back are vague, hedged, or wildly far apart.

Start with the problem, not the screens

The most useful thing you can hand us is the problem in plain language: who has it, what they do today instead, and what it costs them. When we understand the problem, we can propose a shape you had not thought of, and often a smaller one. When we only get a screen list, all we can do is price the screens. You lose the part where a good partner saves you money by building less.

A brief that opens with "our warehouse staff track stock on paper and we lose a day a week to it" tells us more than three pages of feature bullets. It gives every later decision a reason to point back to. If a feature does not help the warehouse staff put down the paper, it can wait. That single sentence does more scoping work than a whole requirements document.

Say what done looks like

Every brief should name how you will know the project worked, in numbers if you can. Fewer support tickets. A booking that takes two minutes instead of ten. A report that runs itself on Monday morning instead of eating someone's afternoon. This is the part teams skip most, and it is the part that keeps a build honest. Without a definition of done, scope has no referee and every request starts to sound equally urgent.

The problem in one or two sentences, and who actually feels it.
What people do today, even if the answer is a spreadsheet or a WhatsApp group.
What success looks like, ideally as a number you can check later.
Hard constraints: a real deadline, a budget range, and any systems it must talk to.
What is explicitly out of scope for the first version.

Put a budget range in. We know the advice online tells you to hide it, but that advice is written for a game we do not play. A range lets us propose the right size of solution instead of guessing, and it tells you quickly whether we are even the right fit. A brief with no budget and no deadline is a wish, and wishes are expensive to quote and slow to answer.

Leave the solution loose

The trap is writing the brief as if you have already designed the product. Naming the database, the framework, or the exact screens locks a builder into your guess before anyone has questioned it. Describe the outcome and the constraints, then let the people you are paying for judgment actually use it. If we agree with your technical calls we will say so. If we do not, you want to hear that during the brief, not after the first invoice.

A brief is not the plan. It is just enough for a good builder to argue with you before you have spent anything.

The best briefs we get are a page, sometimes two. They are honest about the budget, clear about the deadline, specific about the problem, and loose about the solution. They take an afternoon to write and they save weeks, because everything that follows has something real to point back to. And if writing one feels hard, that is useful information too. It usually means the problem is not clear enough to build yet, and a short call will do more than a long document ever could.