How to brief a software development agency (and get comparable proposals)

Most briefs we receive are feature lists. "We need a portal with login, dashboards, reporting, notifications and an admin area." Every agency that reads it will picture a different system and price a different team, and the buyer then tries to compare five proposals that are answering five different questions.

A better brief describes the problem, the people who have it, the constraints, and what success looks like, and it leaves the solution open. It is shorter to write than a feature list and it produces proposals you can put side by side. The rest of this piece covers what goes in the brief and how to read the proposals that come back.

What to include

The problem, in operational terms

"We need a new CRM" tells an agency almost nothing. "Our account managers spend around six hours a week each reconciling customer information across three systems, and we lose roughly two renewals a quarter because nobody saw the notice period coming" tells them a great deal. Say what is slow, what is expensive, what goes wrong and how often. If you have numbers (hours, error rates, revenue at risk, ticket volumes), include them. If you do not, say roughly, and say it is rough. A good agency will help you firm them up.

The users

Who will use it, how many of them, how often, on what devices and in what conditions. A back-office team of twelve on desktops is a different product from 300 engineers in vans on mobiles with patchy signal, even if the feature list looks similar. Mention the awkward cases as well: the seasonal temps, the one customer who insists on CSV uploads and the director who will only look at it on an iPad.

Existing systems and data

List every system the new software must talk to, and say what state each one is in. "Sage 200 via its API, a Salesforce instance we intend to keep, and an Access database that runs pricing and that nobody fully understands" is a useful sentence. Note who owns each system internally and whether documentation, sandboxes or API access exist. Integration is where estimates go wrong, so the more you disclose here, the tighter the ranges you get back.

Constraints

Regulatory (data residency, GDPR specifics, sector rules such as FCA or clinical safety standards), technical (must run on Azure because that is where everything else is, must support single sign-on with your identity provider), organisational (an IT team that will host and maintain it, or one that will not) and commercial (a contract that ends on a date, a peak season you cannot disrupt).

Success metrics

How you will know it worked, in terms you could measure six months after launch. "Reconciliation time under one hour a week per account manager"; "zero missed renewal notices"; "95% of orders entered without support intervention". Two to four is enough. These shape the proposals more than anything else in the brief, because they tell the agency what to optimise for and what can be simplified.

Budget range and timeline

Include both. Buyers often withhold the budget for fear that every proposal will magically match it. In practice, withholding it guarantees that half the proposals are unaffordable and the other half have guessed low to get in the room. A range ("we have provisionally allocated £150k to £250k for the first phase") lets an agency tell you what is achievable and, more usefully, what they would defer. Say whether the timeline is a hard deadline (regulatory, contractual, seasonal) or a preference. Those get treated differently, and should be.

Decision process

Who is deciding, by when, and on what basis. Say whether you want a discovery phase first or a full build proposal, and whether you expect to meet the team who would build it.

What to leave open

Resist specifying the solution. Do not name the tech stack unless there is a real constraint; a brief that says "must be built in React with a Node backend" has just excluded a better answer without knowing it. Leave out the screens, the team size and the day rates, and let the agency propose the delivery methodology.

The point of leaving these open is that the answers are how you tell agencies apart. If you have pre-decided everything, every proposal converges on the same shape and you are left comparing on price alone, which is the worst basis available.

A short brief that does this well is three to six pages. Anything longer is usually a requirements document, and it belongs as an input to a discovery phase rather than in a tender.

How to evaluate the responses

Read the proposals against the brief before you read them against each other, and look for these things in roughly this order:

1. Did they engage with the problem? A proposal that restates your problem in its own words, challenges an assumption or asks a question you had not considered was written by someone who thought about it. One that repeats your bullet points and appends a price came out of a template.
2. Is the scope explicit? What is in the first release, what is deferred, and why. Proposals that do not say what is out of scope are hiding it.
3. Are the estimates ranged and the assumptions listed? A single number for a build of any size is a warning sign. See our note on what a discovery phase should deliver for what a properly ranged estimate looks like.
4. Do they say what they need from you? Access, decisions, content, user availability. The proposals that list your obligations are from teams who have been burned by their absence.
5. What do they say about after launch? Handover, documentation, support, and who owns the code and infrastructure, because silence here gets expensive later.
6. Then price. Normalised for scope and for who is on the team.

If two proposals are close, ask both agencies the same follow-up question in writing ("what would you cut if the budget were 30% lower, and what would you add if it were 30% higher?") and compare the quality of the reasoning.

Questions to ask about the team

Who, specifically, will do the work? Names, roles, experience, and how much of their time. Ask to meet the technical lead before you sign, whoever else is in the room. If the people in the pitch will not be on the project, ask why.

How many of the engineers are experienced, and who reviews the code? A team of one senior engineer and four juniors is priced attractively and delivers slowly. Two or three experienced engineers with one mid-level will usually beat it on both cost and quality.

Will the team be dedicated or shared? Engineers split across three clients context-switch badly. Ask what percentage of each person's week you are getting.

Who owns the code, the repositories, the cloud accounts and the domain? The answer should be "you, from day one, in accounts you control". Any other answer is a lock-in mechanism.

How do you handle changes in scope? Everyone allows them. The useful answer describes the mechanism, meaning how a change is estimated, who approves it and how it affects the schedule.

How will I see progress? A good answer is working software in a staging environment every fortnight. Weekly status reports are a poor substitute.

What happens when something is late? Every project has a difficult month. Ask how they communicate it, what they cut, and for an example.

Can I speak to a client whose project went badly at some point? Every honest agency has one, and how they handled it tells you more than the reference who says everything was wonderful.

Where to start

Draft the brief in a single sitting using the headings above, then give it to someone outside the project and ask them to describe back to you what the software would do and for whom. If they cannot, sharpen the problem statement and the users. Those two sections carry the rest. Then send it to a shortlist of three or four, no more, and give them a fortnight. If you would like a sample brief structure or an opinion on whether yours is ready to send, we are happy to look at it. It is the same document we would use to plan the first stage of an engagement.