How to write a project brief that actually gets you accurate quotes

A UK-based SaaS company sent the same project brief to three development agencies last year. The quotes came back at £28,000, £65,000, and £110,000.

Same project. Same brief. Nearly a 4x spread.

You'd think the agencies were just wildly different in pricing. But when a project manager dug into the proposals, the real problem became obvious: the brief was vague enough that each agency interpreted the scope differently. The cheapest one assumed a basic MVP with one user role. The most expensive one assumed a full platform with admin dashboards, API integrations, and six months of post-launch support.

Nobody was wrong. The brief just didn't say.

Why this happens more than you'd expect

Most founders I talk to skip writing a real brief. They jump on a call, describe what they want in 20 minutes, and wait for a quote. Or they send a few paragraphs over email with bullet points like "user login," "dashboard," and "payment integration."

That's not a brief. That's a wish list.

And wish lists get you wish-list pricing. Every agency fills in the blanks differently, based on their own assumptions about what you meant. Some assume the simplest version because they want to win the deal on price. Others assume the most complex version because they've been burned by scope creep and they're padding.

The result is quotes you can't actually compare. You end up picking the cheapest one and hoping it works out, or going with the most expensive one because "they must know what they're doing." Neither approach is great.

What a usable project brief actually looks like

I've seen hundreds of briefs come through over the past seven years in IT outsourcing. The ones that get consistent, comparable quotes from different agencies share five things (not because five is a magic number, but because anything less leaves too many gaps and anything more turns into a 40-page requirements doc nobody reads).

The problem you're solving, not the features you want. "We need a booking system" tells an agency nothing. "Our customers currently book appointments by calling our office, we lose about 30% of calls during peak hours, and we want to move to online booking that syncs with our existing Google Calendar setup" tells them everything. One sentence of context saves weeks of back-and-forth later.

Who's using it. A project with two user types (say, customers and admins) is fundamentally different from one with five user types, each with different permission levels. If you don't spell this out, one agency assumes two roles and another assumes six. Their quotes will reflect that.

What you've already built. If you have an existing system, say what it runs on. If you have an API that the new thing needs to connect to, say that. If you're starting from zero, say that too. The number-one reason quotes vary wildly is that agencies don't know what they're building on top of.

Your actual budget range. This feels counterintuitive. Most founders don't want to share their budget because they're worried an agency will just quote exactly that number. But here's what actually happens when you don't share it: you get one quote at £28k and another at £110k, and you have no idea which one is closer to reality. If your budget is £40-60k, put that in the brief. Agencies that can't do it for that range will tell you upfront instead of wasting everyone's time. And the ones who can will scope their proposal to fit.

Timeline and hard deadlines. "ASAP" is not a timeline. If you need the MVP live before a funding round in March, say so. If there's no real deadline and you're flexible, say that too. Rushed timelines cost 20-40% more because agencies need to pull in extra developers, and they should be pricing that in from the start, not surprising you with it halfway through.

The mistakes that cost you the most

I keep seeing the same two patterns in briefs that lead to bad quotes.

The first is listing features without context. "User authentication, dashboard, notifications, payment processing, admin panel, reporting." That tells me what modules you want. It tells me nothing about how complex each one is. "Reporting" could mean a single page with a bar chart, or it could mean a 15-table analytics suite with CSV exports and scheduled email reports. If you don't specify, every agency will guess differently.

The second is marking everything as high priority. When everything is priority one, nothing is. Break your features into what needs to be in the first release versus what can come in v2. This does two things: it makes the initial quote smaller and more realistic, and it lets you test the agency's work before committing to the full build.

A simple structure that works

You don't need a 20-page document. A solid brief runs 2-4 pages and covers:

A paragraph about your company and what problem you're solving. Two paragraphs about who uses the product and what they need to do. A list of features broken into "must have for launch" and "nice to have for later." Any technical constraints (existing systems, required integrations, specific platforms like iOS or Android or both). Your budget range. Your timeline. How you want to evaluate proposals (price only? team experience? timeline? all of the above?).

That's it. You can write this in an afternoon.

What happens when you send a good brief

The quotes get closer together. Instead of a 4x spread, you'll see maybe a 1.5x to 2x range, which is normal because agencies have different team sizes, locations, and overhead costs. But now you're comparing apples to apples instead of apples to construction equipment.

You also get better proposals. Agencies respond differently when they can tell you've thought this through. They ask sharper follow-up questions. They propose things you hadn't considered. They're honest about what's hard and what's easy.

And the project goes smoother after you pick someone, because the brief becomes the reference document both sides point to when there's a question about scope.

I work with founders across the UAE, UK, and Australia who are outsourcing development for the first time. The biggest time-saver I can give any of them is this: spend one afternoon writing a proper brief before you talk to a single agency. The quotes will make more sense, the conversations will be more productive, and you'll make a better decision with less stress.

If you want a second pair of eyes on your brief before you send it out, I'm happy to take a look. You can reach me through kejaldave.com.