How to Brief a Development Agency Properly

Describe the problem, not the solution

The most common briefing mistake is arriving with a feature list. A feature list is an answer, and it was written before anyone with technical experience had looked at the question. Every supplier who receives it will quote for building it, including the third of it that will turn out to be unnecessary.

Describe instead what is going wrong, who it affects and what it costs. A good supplier will come back with a smaller build than you imagined, which is exactly what you want from the expertise you are buying.

The five sentences that matter most

1. Today, this is how it works: the current process, in order, including the manual parts.
2. The problem with that is: the specific cost — hours, errors, lost sales, risk.
3. The people involved are: who does it now, who would use the new thing, who has to approve it.
4. We will know it worked if: one measurable outcome.
5. The constraints are: budget, deadline, systems that cannot change, compliance.

Five paragraphs against those headings will get you a more accurate quote than a fifty-page requirements document, because they tell a supplier what to design towards rather than what to price.

Include the awkward parts

The brief that gets you a good result includes the things you would rather not put in writing: the previous attempt that failed, the department that opposes the project, the system you are contractually stuck with until 2028, the fact that the deadline is really about a board meeting.

Every constraint you hide gets discovered in week six, and by then it costs money to accommodate instead of being free to design around.

Say the budget

Withholding the budget to “see what they come back with” is common and self-defeating. Software scope is elastic — the same problem can be solved for £8,000 or £80,000, and both can be correct. Without a number, a supplier is guessing which project you want.

A range is enough. “Under £25,000 for phase one, more available if it works” tells a supplier exactly how to shape the proposal, and lets them tell you quickly if it does not fit.

What to leave out

• The technology stack, unless you have a genuine constraint — an in-house team, an existing system, a compliance requirement
• Database design and architecture — that is what you are hiring for
• Screen-by-screen wireframes, unless a designer you trust made them
• Exhaustive edge cases — the main flows and the constraints are enough at brief stage

If you do have a stack constraint, say so and say why. “Must be PHP because our internal team maintains it” is a legitimate and useful constraint. “Must be PHP” with no reason invites a supplier to quietly ignore it.

How to compare the responses

Read the exclusions before the price. A cheaper quote is frequently a smaller scope, and the differences hide in what each supplier assumed they were not doing.

1. Line up the exclusions side by side — migration, testing, content, training
2. Check which assumptions each supplier listed, and whether any were verified
3. Ask each one what they think the riskiest part is; a supplier who says “nothing” has not looked
4. Ask who specifically will do the work, by name
5. Ask what happens if it overruns, and whether that is written down

The supplier who tells you the awkward thing at proposal stage is the one who will tell you the awkward thing in month three, when it matters far more.

Frequently asked questions