How to Write a Software Brief That Gets You Accurate Quotes

Most quotes that go wrong were doomed at the brief. Not because anyone lied, but because the brief left enough room for two reasonable people to picture two different products — and the price was attached to the cheaper picture.

This is a guide to writing the document that stops that happening. It is also, quietly, a guide to thinking clearly about your own project, which is the part that pays off whether you hire anyone or not.

Start with the problem, not the solution

The single most common opening line in a brief is a description of a feature. "We need an app where users can book appointments."

That skips the only thing a good development team actually needs: what goes wrong today. Who is inconvenienced, how often, and what it costs you. Bookings taken over WhatsApp and copied into a spreadsheet, double-bookings twice a week, an hour a day of someone's time — that is a brief. It tells us what success looks like and, more usefully, it leaves room for someone to point out that you might not need an app at all.

If a paragraph in your brief could be deleted without anyone noticing, delete it. If the problem statement could be deleted without anyone noticing, you have not written one.

Name the users, separately

Write a short paragraph for each type of person who will touch the system. Not personas with names and hobbies — just role, what they are trying to do, and what device they are on.

This matters more than almost anything else in the document, because each distinct user type with its own permissions roughly adds a whole area of work: its own screens, its own rules about what it can see, its own testing. A brief that says "users" when it means customers, staff and administrators is describing three products while paying for one.

Separate must-have from want

Two lists. Be honest about which is which.

The test for a must-have is simple: if this is missing on launch day, do we still launch? If the answer is yes, it is a want. Most lists shrink by half under that question, and the half that survives is the thing worth quoting.

Do not delete the wants. Put them in a clearly labelled second list. They tell whoever is quoting where the product is heading, which changes how they build the first version — a system that expects a second user type later is architected differently from one that does not.

Say what it has to talk to

Integrations are where estimates go wrong most violently, because from the outside they all look the same size and they are not.

For each system you need to connect to, write down its name, whether you have credentials and documentation, and whether anyone at your organisation controls it. "Sync with our accounting software" can mean a day of work against a well-documented modern API, or six weeks against a legacy system with no test environment and a vendor who answers email weekly. Nobody can tell which from the sentence alone.

Payments, identity, mapping, messaging, ERP, anything with compliance attached — list them all, even the ones you think are trivial.

State the constraints you actually have

Constraints make quotes more accurate, not less competitive. Include:

Deadlines with reasons. "By March" is a wish. "Before the trade show on 14 March, because that is where we launch" is a constraint, and it lets someone tell you honestly whether it is possible and what would have to come out.

Regulatory or contractual obligations. Where data may be stored, who must be able to audit it, any client requirement you have signed up to. These are cheap to design for at the start and painful to retrofit.

Existing systems and decisions you will not revisit. If you are staying on a particular platform, say so.

Who is available on your side. A project needs someone who can answer questions within a day and make decisions. If that person has four hours a week, the timeline changes, and it is better to know now.

On budget

You will be told, often, never to reveal your budget. It is bad advice.

A budget range is not a number to be spent; it is a filter. It tells whoever is quoting which version of your project to describe. Without it you will get proposals for products at wildly different scales and no basis for comparing them, and everyone wastes a fortnight.

If you genuinely do not know, say what the project is worth to you instead — what the problem currently costs, or what you expect to gain. That gives the same signal from the other direction.

We do not publish price lists, because a price list for software is a fiction. What we can do, given a brief like this, is tell you what a sensible version costs and what has to change to fit a smaller number.

What to leave out

The technology, unless you have a reason. You are buying an outcome. Specifying a framework because you read about it narrows your options and occasionally prices out the best answer.

Screen-by-screen descriptions. These take days to write and are usually wrong, because they encode assumptions you have not tested. Describe the job; let the design work happen where it belongs.

"Simple", "just", "basic". These words do no work. Every project is simple in the sentence that describes it.

The one-page test

When the brief is done, read only the first page and ask: could a competent stranger tell me what this product is for, who uses it, and what would count as success?

If yes, you will get quotes you can compare. If not, you will get quotes you can only rank by price, which is how projects go wrong before they start.

What good responses look like

A brief this clear should produce responses that disagree with parts of it. Someone should push back on scope, question an assumption, or suggest a smaller first version — often an MVP built in six weeks rather than the whole thing at once. That is the signal you are looking for. A proposal that simply restates your brief with a price attached tells you nothing about whether the team thought about it.

If you have a brief and want a straight answer on scope, timeline and what to cut — including the version where we say the project is not worth doing — send it over.