
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Get the 4DPrime advantage. Talk to a friendly expert about launching your next project — no obligation, no auto-responders.