How to Write a Freelance Project Brief That Gets Great Proposals

Why your brief decides the quality of your proposals

The proposals you receive are a mirror of the brief you wrote. Two sentences and a budget come back as two sentences and a price. A brief that demonstrates you've thought about goals, audience, deliverables, and constraints comes back with proposals that are specific, detailed, and grounded in your actual situation.

This isn't because freelancers are lazy. It's because experienced freelancers self-select. A senior copywriter or developer reads a vague brief and assumes the buyer hasn't thought it through — and they decline, because the project will almost certainly drift in scope. The freelancers who do reply to vague briefs tend to be the ones who'll bid low to win the work and renegotiate later. A clear brief is the most efficient filter you have.

Section 1: The project overview

Two to four sentences. What is this project, in plain English? Who are you, what do you do, and why are you commissioning the work?

Don't write a company history. Don't open with your mission statement. Open with the actual thing. "We run a Shopify store selling handmade ceramics. We need a six-page brand brochure for a London trade show in March." That's an overview.

The mistake here is one of two extremes — either too little ("Need website") or too much (three paragraphs about the state of your industry). The freelancer needs enough context to picture your situation in about ten seconds.

Section 2: Goals (outcome, not output)

This is where most briefs fall apart. Buyers describe what they want made instead of what they want it to achieve.

"Write five blog posts" is an output. "Drive organic search traffic for buyers researching eco-friendly packaging suppliers" is a goal. The freelancer needs the goal to make good decisions about the output. A copywriter who only knows you want five blog posts will write five generic blog posts. A copywriter who knows the goal will pitch a content cluster, target the right keywords, and ask whether a single pillar page would work harder than five short ones.

State the goal even if you think it's obvious. Especially if you think it's obvious — what's obvious to you isn't obvious from the outside.

Section 3: Deliverables

Now, the output. Be specific. "A logo" is not a deliverable. "A primary logo, a secondary horizontal lockup, a favicon, source files in AI/SVG/PNG, and a one-page brand colour and typography guide" is a deliverable.

If you don't know exactly what you need, that's fine — say so. "Likely a logo plus brand basics, open to your recommendation" is honest, and it gives the freelancer permission to scope it for you. That permission, named explicitly, often produces the best proposals of all because it invites craft instead of compliance.

Section 4: Audience and tone

Who is this for? B2B procurement managers and 22-year-old TikTok scrollers don't get the same copy, design, or photography. Tell the freelancer who's on the receiving end — demographic, context of use, what they care about.

Tone matters too. Pick two or three adjectives — "warm but professional", "irreverent and quick", "clinical and credible". If you have a brand that's already speaking somewhere, link to it. Three real-world examples of voices you like will save more revisions than ten paragraphs of guidance.

Section 5: Constraints

Brand guidelines, tech stack, must-include elements, do-not-touch elements, regulatory requirements, accessibility standards, integrations with existing systems. List them.

Freelancers can work around almost any constraint, but only if they know about it before they start. Constraints discovered in revision two are how projects double in cost. The accessibility requirement, the legal disclaimer, the colleague's pet peeve about the Oxford comma — name them up front.

• Brand assets the work has to fit alongside (logo, palette, typography)
• Technical constraints (CMS, framework, hosting, file formats)
• Regulatory or accessibility requirements (GDPR, WCAG 2.1 AA, sector-specific rules)
• Internal stakeholders who will sign off and what they care about

Section 6: Budget range

Yes, share your budget. The argument against — "they'll just match my budget" — is true for the wrong freelancer and false for the right one. Senior freelancers use your budget to scope appropriately. They'll tell you what £500 buys, what £2,000 buys, what £5,000 buys, and that conversation is the most useful one you'll have before hiring.

A range is fine. "£800 to £1,500" is fine. "Open to proposals" is not — it filters out the people you actually want, because they won't spend an hour scoping a project that might pay £200. On Zinn Hub, the project form has separate minimum and maximum budget fields specifically to make this honest range conversation happen up front.

Section 7: Timeline and urgency

When do you need this? Be honest about whether the deadline is real or aspirational. "Final delivery by 14 March because of a trade show" is real. "ASAP" is not a timeline.

If the project is genuinely urgent, mark it as such — Zinn Hub has an urgent flag on the project form that prioritises matching to faster-responding Zinners. But "urgent" should mean urgent, not "I'd like it soon". The flag works because buyers don't abuse it; if you mark every project urgent, you train experienced freelancers to ignore the signal.

Good vs bad: the same brief two ways

Same project, same buyer, same budget. The difference between these two is the difference between three usable proposals and thirty unusable ones.

How much detail is too much

There's a point of diminishing returns. A 12-page brief signals indecision and scares off senior freelancers — they read it and assume revisions will be brutal, sign-off will be slow, and every sentence will be defended in a meeting. Aim for one page of actual content, plus links to references and existing assets. The goal is "enough for a confident proposal", not "complete project specification".

If you find your brief running over a page, the usual fix is removing decisions you haven't actually made yet. You don't need to specify what you'll specify after the freelancer's first round of questions. Leave room for them to ask.

Using the Zinn Hub project form

The structured project form on /projects/ does much of the heavy lifting. Each field exists because it correlates strongly with proposal quality.

Once you post, qualified Zinners in your category get auto-matched and notified. You're not waiting for someone to stumble across your post — the project finds the right people, and they see it inside their notifications, not buried in a feed.

After you post: what to expect

Strong proposals show three things: that the freelancer read your brief (specific references, not generic boilerplate), that they understand the goal (their proposal explains how their approach delivers the outcome you described), and that they've scoped a real piece of work (a clear deliverable, a clear price, a clear timeline).

If a proposal doesn't show all three, ask. A short message saying "thanks — could you tell me how you'd approach the audience question specifically?" filters the serious from the form-letter in about a day. The freelancers who reply thoughtfully are the ones worth shortlisting.

And if you're stuck before you even post — Zinn Concierge is a free 1-to-1 with me to talk through the project before it goes live. Five minutes on a call has saved buyers a lot of revision rounds.