Business2 min read364 words

How to write a developer brief that gets you a real quote

Most developer briefs get rejected or padded by 40%. Here is the exact structure I want to see — and the four sections that turn a fuzzy idea into a precise quote.

I get a few briefs a week. The good ones turn into projects. The bad ones get a polite "not the right fit." The difference is structural, not stylistic. Here is what to put in yours.

1. The one-sentence problem

Start with the problem in one sentence. Not the solution. Not the features. The problem.

Good: *"Our restaurant clients spend 6 hours a week sending follow-up emails by hand."*

Bad: *"We need a CRM with email automation, integrations and a mobile app."*

The first one invites a developer to think. The second one limits them to your half-baked solution.

2. The user and the moment

Who uses this, when, on what device. Three sentences max.

Specific is good: *"Restaurant managers, on their phone, between 10pm and midnight after closing."* Generic is useless: *"Small business owners."*

3. The non-negotiables

Three to five must-haves. Be ruthless. Everything else is a nice-to-have.

If you list 15 must-haves, the freelancer will quote for all 15 and you'll get a quote 4x your budget. If you list 3, you get a quote you can actually consider and a conversation about whether items 4-7 should be added.

4. Budget and timeline

Two numbers. A range is fine.

  • Budget: *"$8-12k for the first version."*
  • Timeline: *"Want to launch by end of September, hard launch deadline October 15."*

Without these, every quote you get is fiction. With them, freelancers self-select and you waste no calls.

5. The stuff that's NOT on the list

This is the section most briefs skip and it's the most useful.

  • *"We do NOT need mobile apps."*
  • *"We are NOT replacing the existing accounting tool."*
  • *"We have NO design system; pick something reasonable."*

Negative scope cuts the quote in half and saves a 45-minute call clarifying what isn't included.

The brief template

```
PROBLEM (1 sentence)
USER (3 sentences: who, when, what device)
MUST-HAVES (3-5 bullets)
BUDGET ($X-$Y)
TIMELINE (start date, launch date)
NOT IN SCOPE (3-5 bullets)
EXISTING (what's already built, links if possible)
SUCCESS LOOKS LIKE (1 measurable sentence)
```

That's it. Fits on one page. Gets you fast, honest, comparable quotes. Use it.

Frequently asked

Common questions

How long should a developer brief be?
One to two pages. Long enough to answer the four core questions, short enough that a busy freelancer reads it on a phone.
Should I include a budget?
Yes. 'Budget unstated' is a yellow flag — it means either you don't know (then say so) or you're hoping for a lowball. Either way, name a range.
Written by
Oxymore

Oxymore is a one-person studio shipping MVPs, landing pages, React apps and Telegram bots for founders who would rather move than meet.

Last updated