How to write a project brief that gets good bids
A bad brief does not get fewer bids. It gets more — from people who have not understood the job and are guessing at the price.
By The Nepal Can Work team · Updated
There is a counter-intuitive thing about posting freelance work: a vague brief gets more responses, not fewer. It just gets them from the wrong people. Freelancers who read carefully and quote accurately cannot quote at all on an ambiguous job, so they skip it — and the ones who reply are the ones who did not need to understand it to say yes.
Fixing this is mostly mechanical. Here is the structure.
1. Say what the finished thing is, as a list of files
The most common mistake is describing an outcome instead of a deliverable. 'I need a better online presence' is a wish. 'A five-page website, source in a Git repo, deployed to a URL' is a deliverable.
| Wish | Deliverable |
|---|---|
| A nice logo | Primary logo + horizontal lockup + favicon, as SVG and PNG |
| Some social media content | 12 Instagram posts, 1080×1080, with captions, as editable files |
| Help with my website | Fix 6 listed bugs on an existing WordPress site, on a staging copy first |
| Video editing | One 90-second edit from 40 minutes of supplied footage, 1080p MP4, with subtitles |
If you cannot write the right-hand column yet, that is genuinely useful information — it means the job is not defined enough to price, and the first thing to buy might be a short paid consultation rather than the work itself.
2. Say what done looks like
Write the condition under which you will approve the work. Not as a threat — as a target, so the freelancer knows what they are aiming at.
- 'Approved when the six listed bugs no longer reproduce on staging in Chrome and Safari.'
- 'Approved when the logo works legibly at 32px and on a dark background.'
- 'Approved when the copy is under 500 words per page and mentions the three products listed below.'
This is also the document a dispute is judged against, if one ever happens. A brief with a clear definition of done is very hard to argue about; one without it is very hard to resolve.
3. Give the constraints you already know
Every constraint you withhold becomes a revision later:
- Brand colours, fonts, existing assets — attach them, do not describe them.
- The tech you are locked into. If it must be WordPress, say so before someone quotes for a rebuild in something else.
- Who the audience is. 'Nepali small business owners aged 30–50' produces very different work than 'international tech buyers'.
- Things you already know you dislike. Two or three examples save an entire revision round.
4. State the budget — actually state it
Withholding the budget to 'see what they say' is a false economy. It produces a spread of quotes anchored on nothing, and you end up comparing bids that assume completely different scopes.
A stated budget lets a freelancer tell you the honest thing: what is achievable for that money. That answer is worth more than a low bid from someone who will discover the problem halfway through and either cut corners or ask for more.
A range works fine
'Rs. 15,000–25,000 depending on scope' is a perfectly good budget line. It gives an anchor without committing you, and it filters out both the people who are far too expensive and the ones quoting far too little to have understood the job.
5. Give a real deadline, and name your own dependencies
Two failures here. The first is a fake-urgent deadline, which just makes careful people skip your post. The second — much more common — is not mentioning what you owe.
If the freelancer needs your product photos, your copy, or access to your hosting, say when they will get them. Most projects that run late run late because the client's side of the dependency arrived a week after it was assumed.
6. Set the revision count
Two rounds is a reasonable default. Say it in the brief. 'Unlimited revisions' sounds generous and is the single most reliable predictor of a project ending badly — it removes any point at which the work is finished, which is bad for both sides.
A template you can copy
What I need: [deliverable, as a file list] Done means: [the condition for approval] Context: [audience, brand assets attached, tech constraints] Budget: Rs. [range] Deadline: [date]. I will provide [your dependencies] by [date]. Revisions: 2 rounds included. Please tell me: [one question that requires having read the brief]
That last line is the highest-value sentence in the whole brief. Ask something specific — 'which of the two approaches below would you take, and why?' — and the replies sort themselves instantly. Anyone who ignores it has not read the rest either.
What good replies look like
- They ask a clarifying question before committing to a price. This is a good sign, not hesitation.
- They quote a specific number and a specific timeline, not 'depends' or 'let us discuss'.
- They reference your actual brief rather than pasting a template introduction.
- They show relevant work, in your category, not their best work in any category.