Experience

How to Write a Software Brief That Gets Accurate Quotes

Feature image

The single biggest cause of misquoted, mis-scoped and ultimately disappointing software projects is a vague brief. When agencies are quoting against different assumptions, you can’t compare them — and you’ll usually pick the cheapest one, who turns out to have assumed the least. A good brief levels the field, surfaces decisions early and lets serious teams price what you actually want. Here’s how to write one. It will take you a few hours. It will save you, conservatively, weeks.

What a Brief Is For

A brief is not a specification. You don’t need to know what database to use, what framework to build in or how the screens are laid out. That’s the agency’s job. What the brief needs to do is communicate what success looks like clearly enough that two different agencies, reading it cold, would scope roughly the same project.

If your brief leaves room for interpretation, the cheaper agency will interpret it cheaply and the more expensive one will interpret it thoroughly — and you’ll be comparing apples to oranges.

The Sections That Matter

1. Background and context

Two or three paragraphs. Who you are, what your business does, what’s prompting this project now. The reader should finish this section understanding why the project exists, not just what it is.

2. The problem you’re solving

State the actual problem in plain English, before talking about the solution. “Our sales team currently re-keys order data into three systems” is a problem. “We need a CRM” is a solution. Briefs that lead with solutions get quotes for the wrong thing.

3. The users

For each type of user, write:

This is the single most underweighted section in most briefs, and it changes the architecture more than any other input.

4. Must-haves vs nice-to-haves

List features in two columns. Be ruthless. If something is a “nice to have”, say so — agencies can quote it as an optional phase rather than burying its cost in the main number.

Things to flag explicitly: anything real-time, anything offline, anything involving payments, anything involving integrations, anything involving file uploads over ~10MB, anything that needs to work without internet, anything that needs an admin panel.

5. Integrations

Name them. For each one, say:

Integrations are the single most common source of cost overruns. Saying “and it needs to talk to our existing system” is not enough.

6. Success metrics

How will you know the project worked? “Users adopt it within three months”, “we save four hours per week per user”, “we reduce support tickets by 40%“. Even rough numbers are better than none — they help the team prioritise and tell you whether the proposal is solving for the right thing.

7. Constraints

Anything fixed that the team needs to know about up front: budget ceiling, must-launch-by date, regulatory requirements, hosting preferences (e.g. on-premise, specific cloud), accessibility level required, brand guidelines, existing tech stack you have to live with.

8. What’s out of scope

Equally important — the things you specifically don’t want included. This stops generous agencies from quoting a bigger project than you asked for, and lets honest ones flag if they think something out of scope is actually essential.

9. Timeline expectations

If you have a deadline, name it and explain why. “We want to launch before our trade show on the 14th of October” is workable. “ASAP” is meaningless and will be priced for risk.

10. Budget

Most clients hide their budget, worried agencies will quote up to it. In practice the opposite happens: agencies guess and quote either too high (and lose your business) or too low (and cut corners). A range — “we’re working with a budget of £40,000 to £70,000 depending on scope” — gets you the most useful proposals.

How Long Should It Be?

Two to six pages is the sweet spot. Shorter than that and you’re under-specifying. Much longer and you’re spec’ing the build for them, which limits the value they can bring.

A Few Things People Forget

What Happens After You Send It

Expect any serious agency to come back with questions. The depth and specificity of those questions is a useful filter — it tells you which agencies actually read the brief and thought about it, versus which ones lifted a quote from a template.

Three or four well-considered proposals from teams that engaged with your brief is a better outcome than ten that just gave you a number.

Free Template

We keep an evolving template of the sections above as a downloadable document — it’s the same one we share with new clients who ask “where do I even start?” It’s worth using even if you’re talking to other agencies, not just us. The point of a good brief is that it makes the conversation better with whichever team you choose.

Get in touch and we’ll send it over. No strings.

← Back to Blog
Ready when you are

Launch your next idea.

Get the 4DPrime advantage. Talk to a friendly expert about launching your next project — no obligation, no auto-responders.