How to Write a Freelance Project Brief: A Checklist

A freelance project brief explains what you need, why you need it and how you will decide whether the work is complete. It gives the freelancer enough context to make decisions without guessing at your priorities.

“Build us a website” names an output, but leaves the problem open. A website meant to explain three service packages needs different work from one meant to fix a confusing inquiry form. Write the problem first, then describe the deliverable. The checklist and copyable template below help you make that distinction.

Start with the problem and the audience

Describe what is happening now and what you want to change. Use evidence you already have, such as support questions, user feedback or an existing content review. If the problem is only a suspicion, label it as an assumption and ask the freelancer how to investigate it.

Be specific about the audience. “Business owners” could mean a first-time founder or an experienced finance director. Explain what these people already know, what they need to do and where they will use the work. A mobile customer comparing prices needs different information from an operations team reviewing a detailed dashboard.

Separate the intended business outcome from acceptance of the work. You may hope a new landing page increases inquiries, but the freelancer cannot guarantee visitor behavior. Agree instead on deliverables and checks they can reasonably control.

The project-brief checklist

Goals, context and voice

Give a short project overview, the main problem and the desired outcome. Add relevant background rather than your entire company history. Share two or three useful examples and explain what works in each. “Use the clear explanations in this article” is more helpful than “make it professional.”

Include terminology, brand guidelines and anything to avoid. If your brand needs plain language without exaggerated promises, say so. Distinguish requirements from suggestions so the freelancer knows where their judgment is welcome.

Deliverables and exclusions

Specify quantity, format and handoff requirements. For an article, that could mean one researched draft, an agreed word range, source links, metadata and an editable file. For a design project, list the required screens, mobile layouts and source files.

State what is excluded. Does website design include development? Does writing include interviews, images or publishing? A prototype is not a production application. Missing boundaries make two reasonable interpretations possible, even when everyone is acting in good faith.

Budget and payment

State the available budget or ask for a quote against the defined scope. Record the agreed currency, fixed fee or hourly rate, any hours limit, and payment stages. Identify whether subscriptions, licensed images and other expenses are included or need approval.

Agree how additional work will be priced before it starts. The brief should reflect the payment agreement, not replace the contract or the payment service's terms.

Dates, dependencies and review

Use calendar dates and a time zone for the outline, first draft, feedback and final handoff. Add the date when the client must supply materials. A deadline based on approved copy arriving on Monday needs reconsidering if the copy arrives on Thursday.

Name one person to combine stakeholder feedback. Define the number of revision rounds and what each covers. Corrections within the agreed scope differ from adding another page, changing the target audience or requesting a new concept.

Acceptance and changes

Write observable completion checks. “Looks good” gives little guidance; “includes all agreed screens and demonstrates the listed interactions” is easier to review. GOV.UK's guidance on user stories describes acceptance criteria as outcomes used to check that a user need has been met.

Record new requests in a change log with the reason, approver and effect on price or dates. Pause affected work until both sides agree. You do not need to rewrite the whole brief for every small clarification.

Fictional example: a service-comparison page

The following example is invented to show the level of detail. Its dates, fee and review periods are illustrative, not recommended market rates or a client result.

A small consultancy receives repeated questions about the differences between its three service packages. It commissions one comparison-page design for visitors who are considering their first purchase.

• Deliverables: one desktop layout, one mobile layout and an editable design file using approved copy.
• Exclusions: copywriting, development, hosting and changes to the checkout.
• Schedule: approved copy by 9 November 2026; first design by 12 November; combined feedback by 16 November; final handoff by 19 November. All dates use UTC.
• Budget: a fictional fixed fee of USD 600, split between agreed start and final acceptance stages.
• Review: two rounds addressing the agreed comparison page; a separate quote for extra pages.
• Acceptance: all three packages appear with approved prices, differences and next-step links; desktop and mobile layouts include the agreed content; source files open correctly.

This brief leaves room for design choices while making the assignment reviewable. It does not promise a particular increase in sales.

A reusable freelance project brief template

Copy these prompts into a document and replace the brackets. This is an in-page template, not a separate download.

• Project name and decision-maker: [name, contact and final approver].
• Problem and evidence: [what is happening; supporting information; assumptions].
• Audience and goal: [who needs the work and what they need to do].
• Deliverables: [quantity, formats, included work and handoff files].
• Exclusions: [work, costs and ongoing support not included].
• Voice and references: [guidelines, examples and reasons for choosing them].
• Materials and access: [links, permissions, owner and availability date].
• Budget and payment: [currency, price basis, stages and expense approval].
• Schedule: [milestones, client review dates and time zone].
• Feedback: [review owner, included rounds and response window].
• Acceptance: [specific checks and who performs them].
• Open questions and changes: [decision owners and approval process].

Check the brief before sharing it

Gather input from the people who will supply materials and approve delivery. Open every reference link and check that the freelancer will have access. Share only necessary information, and arrange appropriate access rather than putting passwords in the document.

Then ask someone outside the project to explain the assignment back to you. If they cannot identify the output, exclusions or acceptance checks, revise those sections. Remove instructions that repeat the same point and resolve contradictions before requesting a quote.

The Local Government Association's commissioning-brief guide also addresses scope, milestones, dependencies and change control. Its context is infrastructure planning; the template here is an editorial adaptation for smaller freelance assignments, not a procurement procedure.

For marketplace context, see how ALHarih works. Keep your actual scope and payment agreement explicit whichever hiring route you choose.