How to Brief a Dev Agency So You Actually Get What You Want

Every agency has a version of this story: a project that took twice as long as quoted, not because the team was slow, but because the brief kept changing shape as it went. Almost none of that comes down to a bad developer. It comes down to a brief that was clear enough to start, but not clear enough to finish.

What a good brief actually contains

• The problem, not the solution — "our support team is overwhelmed by repeat questions" is a better starting point than "we need a chatbot."
• Who this is for, specifically — not "our customers," but the actual person: their technical comfort level, the device they'll use, whether they're doing this once or every day.
• What "done" looks like, in a sentence a non-technical person could verify.
• Constraints that actually matter — a real launch date tied to an event, a budget ceiling, an existing system it has to work with.
• Examples of what you like and don't like — three competitor sites or apps, with one sentence each on what you'd copy and what you'd avoid.

The three words that cause the most rework

"Something like that." It's a completely natural thing to say in a first conversation, and it's also the single biggest source of scope disagreements later. If a requirement can only be described as "something like that," it's not ready to be built yet.

Why over-specifying can backfire too

The opposite failure mode is real too: a 40-page spec that dictates every pixel before anyone has validated that users actually want the feature. We'd rather get a clear problem statement and a rough sketch, build a scoped-down first version fast, and refine it against real feedback.

A brief's job isn't to remove every decision from the project. It's to make sure the decisions that get made are the right size, at the right time, by the right person.

What we do with a brief once we have it

We turn it into a scope document with explicit "in" and "out" lists — not to be difficult about small requests later, but because the fastest way to blow a timeline is to let scope grow one "just one small thing" at a time without anyone tracking it.

If you're not sure your brief is clear enough yet, that's normal. Book a discovery call — the goal isn't to extract a perfect spec from you, it's to ask the questions that turn "something like that" into something we can actually build.