A brief is good when a developer can read it and say no. That means it contains enough to be judged, which takes four things: what exists now, what "done" means, the constraints that are actually real, and what you can spend. Half a page with those four beats three pages without them.
Everything else is optional. Most briefs that get ignored are missing two or three of the four.
1. What exists now
Nothing, a written spec, finished designs, a half-built app someone else started. Say which.
This matters more than people expect, because the gap between an idea and a specification is real work that somebody has to do. If it is not done, it goes on the quote. If you hand over finished designs and a clear scope, the estimate genuinely comes down.
An existing codebase is the case people get wrong. It feels like a head start, and it often is not: reading someone else's code is work, and what is in there is unknown until someone reads it. Say it is there, say who built it and roughly when, and expect the first slice of any quote to be someone finding out what they are dealing with.
2. What "done" means
One paragraph, written as an outcome rather than a feature list.
This is the one that matters most and the one most often missing. Compare:
Needs a dashboard, user roles, a calendar view, notifications, and an export function.
with:
A manager can build next week's rota in under ten minutes, staff see their shifts on their phone, and swap requests go to the manager for approval.
The first is a shopping list. The second tells a developer what the thing is for, which means they can tell you which parts are hard, which are cheap, and which one you probably do not need in version one. It also gives you both a way to know when you are finished.
If you cannot write that paragraph, that is worth discovering now rather than two months into paying someone. Describe the problem instead: "our rota lives in a spreadsheet and it breaks every time someone swaps a shift" is a brief somebody can respond to.
3. Constraints that are real
A deadline that actually matters. A stack you genuinely cannot leave. A platform you have to ship to. An integration with a system you already run.
The word doing the work there is real. Constraints you invented to sound organised cost you money, because every one of them narrows who can take the job and adds to what they charge. "Must be built in Rails" when you have no Rails team and no Rails codebase is not a constraint, it is a preference you will pay for.
Deadlines are the same. "Live before the summer season" is a constraint. "As soon as possible" is not, and it reads as either a lack of planning or an attempt at pressure.
4. Budget
The part people leave out, and the part that wastes the most time.
Leaving it out does not get you a better price. It gets you fewer replies. A developer with a queue reads an unstated budget as "this will be a long negotiation" and answers the briefs that have a number in them. The ones who do reply have to guess high, because they are pricing the risk of finding out too late.
If you genuinely do not know, say what the work is worth to you instead:
We do not have a fixed budget yet. This replaces about six hours a week of manual admin across four sites, so it earns its cost back reasonably fast. Tell us what you would charge and we will say whether it is in range.
That is an honest sentence, it invites a real conversation, and it is far better than silence.
What to leave out
- Technical solutions you are not qualified to specify. Saying "use a NoSQL database" when you do not know why is worse than saying nothing. You are removing a decision from the person you are paying to make it.
- Twenty features with no priority. If everything is a must-have, nothing is, and the quote covers all of it.
- Company boilerplate. Nobody quoting a two-month build needs your mission statement.
- NDAs before the first conversation. Ask for one when there is something to protect. Leading with paperwork filters out exactly the independent people you are trying to reach.
Send it to more than one person
Three quotes against one written brief is the fastest way to learn what the work is really worth. Say you are doing it, because it is normal and it saves the awkwardness later.
Then read the replies for more than the number. The useful signal is what they ask you. A developer who comes back with the three genuinely ambiguous things in your brief has read it properly. One who quotes immediately with no questions has either built the exact thing before, or has not thought about it.
What good looks like from the other side
Expect a range rather than a figure, at least at first. Expect questions. And expect the honest ones to tell you when part of what you have asked for is not worth building, which is one of the more valuable things you can get out of a first conversation.
Once you have a brief, how to hire a freelance developer without Upwork or Fiverr covers the rest: building a shortlist from work you can actually open, checking a person is real, and structuring the first job so it can fail cheaply.