A vague brief gets a vague quote, and a vague quote is the single biggest source of scope disputes later. Most founders don’t write a bad brief because they’re careless — they write one because nobody’s shown them what a useful brief actually contains.

Here’s a structure that works, and why each part earns its place.

Start with the decision, not the feature list

Before describing any screens, write down the business decision this release needs to inform or the problem it needs to solve. “We want an app for X” is a feature list wearing a brief’s clothes. “We need to find out whether landlords will pay for automated compliance tracking before we build the full platform” is an actual brief, because it tells an agency what the release is for.

This single sentence changes the quote more than almost anything else, because it tells a competent team what to protect and what to cut when trade-offs come up mid-build.

Name the primary user and their one complete journey

Pick the person whose behaviour matters most commercially, and describe the one journey they need to complete start to finish: what brings them in, what they do, where the value becomes visible, what confirms they’re done. Skip the admin views and edge cases for now — those come later, once the core loop is clear.

A brief that tries to describe every user role and every screen at once is usually a brief that hasn’t decided what the release is actually for.

Be explicit about what’s out of scope

This is the part most briefs skip, and it’s the part that prevents the most arguments later. List the things you know you don’t need in the first release, even if they’ll matter eventually. “No admin dashboard in v1” or “manual customer support is fine for the first three months” tells an agency exactly where the boundary is, and gives them something concrete to quote against.

Vague scope isn’t generous, it’s expensive — it forces whoever’s pricing the work to either quote high to cover the unknown, or quote low and renegotiate later.

List real constraints, not aspirational ones

Budget range, timeline, existing systems that need to connect, compliance requirements, and team capacity to manage the work day to day. If you don’t have a firm budget yet, say so honestly and ask for a range instead of a fixed number — that’s a normal, answerable request. What isn’t useful is omitting the constraint and hoping the quote happens to fit.

Bring what already exists

Any research, wireframes, a rough prototype, competitor screenshots, or existing product analytics. None of it needs to be polished. Real, messy context produces a far more accurate quote than a clean brief written from a blank page, because it shows the agency what you’ve already learned rather than making them guess.

What a complete brief looks like, in one page

  1. The decision or problem this release needs to answer.
  2. The primary user and their one complete journey.
  3. What’s explicitly out of scope for this release.
  4. Budget range, timeline, and any hard constraints.
  5. Existing research, prototypes, or systems that need to connect.
  6. How you’ll know the release worked.

That last point matters more than it looks. If you can’t describe what success looks like, that’s worth resolving before the brief goes out, not after the build starts.

What this actually buys you

A brief built this way doesn’t just produce a more accurate number — it lets you compare quotes from different agencies on the same basis, since everyone’s pricing the same defined scope instead of their own guess at what you meant. It also gives you a concrete reference point to hold any agency to once work begins.

Have a rough idea but not a full brief yet? Book a strategy call and we’ll help shape it together — or see how we turn a brief like this into a scoped release on the MVP development page.