How to Brief a Development Agency So the Estimate Is Accurate

Most estimate accuracy problems do not start with the agency — they start with a brief that leaves out details the client did not realise were relevant. This post is a practical checklist, built from the gaps we most often have to fill in during our own discovery calls, that you can use to brief any agency, not just us, so the estimate you get back actually reflects your project rather than a generic assumption about it.

What should actually be in a development brief?

Start with the business problem, not the technical solution. "We need a system where our sales team can track deals through five stages, and management can see conversion rates by stage and by rep" is a far more useful brief than "we need a CRM," because it tells the agency what the software needs to do rather than a category name that could mean a dozen different things at wildly different price points.

List every distinct user role and what each one needs to see and do. This is the single factor that most affects custom software cost, and it is also the detail clients most often undercount, because internal processes accumulate informal roles — "well, our ops lead can also see finance data, but only for their own region" — that never make it into a first draft brief.

How specific do I actually need to be about my current process?

More specific than feels natural. Describe your current process step by step, including the exceptions and workarounds your team currently performs, not just the clean, idealised version of the process. If a step usually happens smoothly but occasionally needs a manager override, say so — that override is exactly the kind of detail that turns into an unplanned mid-project scope discussion if it surfaces for the first time in week six.

Where you have quantifiable numbers, include them: how many records the system needs to handle now and in a year, how many transactions per day at peak, how many concurrent users during your busiest period. An agency that has to guess at scale will either guess conservatively — leading to a system that struggles under real load — or guess generously, inflating the estimate to cover uncertainty you could have removed by simply stating the number.

What should a brief say about what's NOT included?

As much as what is included, if not more. Most scope disputes originate not from a feature nobody mentioned, but from a feature one side assumed was included and the other assumed was not — a common example is whether the quoted price includes migrating data from an existing system. Stating explicit exclusions in your brief — "this project does not need to migrate historical data from our old system" or "this does not include a mobile app, web only for now" — forces both sides to agree on the boundary before a contract is signed, not discover disagreement about it during the build.

Should I include a budget range in my brief?

Yes, and this is a piece of advice some agencies avoid giving because it sounds like it benefits them more than you, but it genuinely helps both sides. A stated budget range lets an agency tell you honestly, early, whether your expectations and your scope are realistic together — either the scope needs to shrink, the budget needs to grow, or you are actually well aligned and can move straight to detailed discovery. Without a budget range, an agency estimating in the dark risks either wildly overshooting what you can spend, wasting everyone's time, or underscoping to hit an assumed number, setting up disappointment later.

What questions should a good agency ask me back?

If your brief is reasonably detailed, a competent agency should still come back with questions about your specific edge cases, your integration requirements in more depth, and how you would prioritise features if the full scope did not fit your budget or timeline. An agency that reads a brief and returns a fixed quote with no clarifying questions at all is either working from a template that ignores your specifics, or planning to treat any gaps as billable change requests later. Neither is a good sign.

How does a good brief actually change the estimate you get back?

It converts a range into a number, and it converts a number you cannot trust into one you can. A vague brief forces an agency to quote against assumptions, which means the number reflects their assumption of your project, not your actual one — and the gap between those two things is exactly where budget overruns come from. A detailed, specific brief lets an agency quote against your real scope from the start, which is the entire point of running a proper discovery phase rather than skipping straight to a number.

Can I use this checklist for a project I'm scoping in-house, not for an agency?

Yes — everything above applies just as well to briefing your own internal team or a hired developer under staff augmentation as it does to briefing an external agency. The underlying discipline is the same: describe the real process, quantify real scale, and state explicit exclusions, regardless of who is going to build the thing.