How to Brief a Developer — A UK Small Business Guide

The most common cause of failed or overbudget development projects is not technical — it is a brief that was not specific enough. A vague brief produces a quote that the developer interprets in their favour, a scope that expands during the project, and a final product that does not quite match what you had in mind. Here is how to write a brief that prevents all three.

Start with the problem, not the solution

Most briefs describe the solution the client wants rather than the problem they are trying to solve. "We need a CRM with a pipeline view and automated follow-up emails" is a solution description. "We lose track of where each prospect is in our sales process and follow-ups happen inconsistently" is a problem description. Starting with the problem gives the developer room to suggest a solution that might be better than the one you had in mind — and ensures the solution actually addresses the underlying issue rather than just building what was described.

Describe who will use it and how

Every good development brief describes the users — not abstractly, but specifically. Who are they? How technical are they? What device will they primarily use? What do they currently do instead of using this tool? What does success look like for them? A brief that answers these questions produces a design that fits the actual users rather than a theoretical average user. This is especially important for internal tools, where the temptation is to assume developers understand the business context — they rarely do without being told.

Define what must work on day one vs what can come later

One of the most effective ways to control cost and timeline is to be explicit about what is essential for launch and what can be added later. A brief that tries to specify everything leads to a large, expensive, slow project. A brief that identifies the minimum viable set of features — the things without which the tool does not solve the problem — leads to a faster, cheaper first version that you can improve based on real use. Be honest with yourself about what is genuinely essential.

Specify what you do not want as clearly as what you do

Negative requirements are as important as positive ones. If you do not want the developer to host your data on servers outside the UK, say so. If you do not want a WordPress site, say so. If you do not want ongoing licence fees for third-party tools embedded in the build, say so. If you do not want to be locked into a proprietary system you cannot move away from, say so. These constraints shape the solution significantly and are far better addressed before the project starts than after.

Related articles