How to brief a software agency (and avoid the biggest mistake clients make)

In the past few years, we've received hundreds of project briefs. Some are two paragraphs. Some are 40-page documents. The length isn't what determines whether a project succeeds. What matters is whether the brief answers the right questions — and avoids the mistake that derails more software projects than any technical problem ever does.

The mistake: describing the solution instead of the problem

This is the single most common and most costly briefing error. A client comes to us with a detailed specification — they want a mobile app with five specific screens, a particular login flow, a dashboard with three widgets. They've already decided what to build. What they haven't told us is why.

The problem is that the solution they've described is almost never the optimal solution. It's the first solution that occurred to them, or the solution they saw a competitor use, or the solution someone on their team suggested in a meeting. It might be fine. It's rarely the best answer to the underlying problem.

“We once had a client who wanted a complex custom reporting tool. After one conversation about the actual problem, we realised they needed a single automated email sent every Monday morning. It took two days to build. It solved the problem completely.”

What a good brief actually covers

The problem and the cost of not solving it

Start here. Describe the specific problem you're trying to solve, who experiences it, how often, and what it costs you today — in time, money, or missed opportunity. This context shapes every decision that follows.

Who the users are

If you're building something people will use, describe those people. Their technical confidence, their environment, what they care about, what frustrates them. 'Our users are warehouse supervisors who use this on tablets while walking the floor' changes the design significantly compared to 'office-based knowledge workers on desktop'.

What success looks like

Define success in measurable terms. Not 'a better experience' — but 'reduce the time it takes to process an order from 4 minutes to under 90 seconds' or 'allow our team to handle 40% more support tickets without adding headcount'. Measurable goals create accountability on both sides.

Constraints that are real

• →Hard deadline (and whether it's actually hard or just preferred)
• →Budget range — even a rough one saves significant time
• →Systems the new build must integrate with
• →Compliance or regulatory requirements
• →Team who will own and maintain it after delivery

What you don't need in a brief

You do not need to specify the tech stack. You do not need to design every screen. You do not need to map every database table. These are the agency's job — and if you prescribe them upfront, you're constraining the solution space before the problem has been properly understood. Good agencies will ask the right questions. Trust the process.

The one thing that makes briefing easier

Talk to the agency before you write the brief. A 30-minute discovery call with the right questions will tell you more about what needs to go in a brief than an hour of writing alone. It also tells you whether the agency is worth working with — a good agency asks questions you hadn't thought of. That's a positive signal.

We offer a free discovery call precisely because the brief matters. Use it before you've fully defined the scope. The output of that call usually is the brief.