How to brief a dev agency (without wasting six weeks)

Most of the wasted time in a software project happens before anyone writes code.

It's the weeks of back-and-forth clarifying what the project actually is. It's the scope that shifts three times because nobody pinned it down on paper. It's the technical constraints that surface on week six, when the wrong foundation is already pouring concrete.

A good brief shortens all of that. Here's the shape of one.

What to put in the brief

A one-paragraph outcome statement. Not features — outcomes. "We want to reduce support ticket volume by 40% through self-service" is a brief. "Build an AI chatbot" is a feature list. The first makes scope decisions easier for everyone downstream.

The two or three things that must be true on launch. Not twenty requirements — the two or three where, if any one fails, the project is a failure. "Must handle 10k concurrent users" or "must pass SOC 2 review in Q3" or "must integrate with Salesforce." Everything else is negotiable.

What you've already ruled out. "We considered Zendesk's native bot and ruled it out because X" saves everyone a conversation.

The deadline and why. "We want it soon" is not a deadline. "Our annual conference is October 15 and we need a working demo" is. The why matters because it tells us what we can and can't cut when we hit the inevitable tradeoff.

Budget range — even if rough. "Under €30,000" or "up to €100,000 depending on scope" is enough. Without it, we both waste time building proposals for the wrong scale of project.

Who the decision makers are. Specifically: who signs the statement of work, who signs off on design, who signs off on launch. Not always the same person. Knowing upfront prevents three-round review cycles.

What not to put in the brief

A technology stack. Unless you have a real constraint ("must run on our existing AWS account") or a real conviction with a reason ("our team is deep in React and won't maintain anything else"), leave the stack to be decided in the kickoff. Specifying the stack in the brief often locks out the best solution before the problem is even discussed.

A feature list longer than one page. You haven't decided which features matter yet. Your dev team can help you decide.

UI sketches of every screen. A mood board and a core-flow sketch are useful. Full screen designs from an external designer before kickoff are usually wrong in subtle ways that cost time to undo.

The kickoff call

A good brief earns you a better kickoff. Come ready to answer:

• What does success look like 3 months after launch, not just at launch?
• What have you already tried that didn't work?
• Who else inside your company needs to be happy with this?

Those three questions, answered honestly, are worth more than any 20-page RFP we've seen.

One last thing

Write it yourself. Don't delegate the brief to an assistant, an agency's account manager, or an AI. The brief is you telling a stranger what you want. The moment that gets filtered through a fourth party, quality drops. The people who write their own briefs ship faster. Every time.