How to write a software brief that gets better quotes

The quality of a quote depends almost entirely on the quality of the brief. A list of features invites guesses. A clear description of the problem invites a plan.

One page, six headings

• The problem: what is slow, expensive or impossible today, and for whom.
• The people: who will use it, how often, and on what devices.
• Must-haves at launch: the few things that have to work on day one.
• Later: the things you want eventually, clearly marked as later.
• Constraints: budget range, deadline, and any systems it must connect to.
• Success: how you will know, six months after launch, that it worked.

Share the budget range

Many teams hide their budget, hoping for a lower quote. The usual result is a proposal designed for a different budget, and a second round of conversations. A range lets a studio tell you honestly what fits, and what would need to wait.

“A good brief describes a problem worth solving. A great one says how you'll know it's solved.”

You don't need technical language. Plain descriptions of what people do today, and what you wish they could do instead, are exactly what a good team needs to start.