How to write a brief a contractor gets on the first read

A good brief isn’t a thick document full of terms — it’s a clearly stated task. The contractor doesn’t need you to know technologies; they need to understand what should come out and why. Here’s a structure that’s enough to start almost any project.

The six blocks of a good brief

• Goal: what the business should gain — “take leads,” “sell online,” “take load off managers.”
• Audience: who uses it and from which device.
• Scenarios: what the person does step by step — “arrived → chose → paid.”
• Examples: 2–3 sites or products you like, with a note on exactly why.
• Constraints: deadlines, budget range, required integrations (payment, CRM).
• Content: what you already have (texts, photos, logo) and what needs to be created.

What you don’t need to do

Don’t try to describe technologies and the “how” — that’s the contractor’s job. Your zone is the “what” and the “why.” If each point above has a couple of clear sentences, you already have a better brief than 80% of incoming requests. Ready-made brief templates for a site, a bot and an app are free in our Tools section.

What this gives you in practice

A clear brief isn’t bureaucracy — it’s insurance for both sides. You get a timeline and budget estimate you can trust, because the contractor counts from specifics, not guesses. And once the project is underway, you can return to this document and check: are we building what we agreed on — or has the scope quietly doubled? Most “you built the wrong thing” conflicts are conflicts of unstated expectations, and they’re resolved right here, on dry land.

What happens to the brief next

A good brief starts the conversation — it doesn’t end it. On receiving the document, a competent contractor comes back with questions, and that’s a good sign: questions mean the task was read and thought about. What should worry you is the opposite — “all clear, we’re starting” an hour after you hit send. The brief then becomes an estimate and a staged plan: what is delivered, when, and what you accept at each step. From that moment the document works as a shared frame of reference — any dispute is settled not by who’s louder but by checking against what was agreed in writing.

Frequently asked questions

• How detailed should a brief be? One or two pages across the six blocks above are enough to start. A thick document at the start usually hurts: it locks decisions before the contractor has asked questions — and revisiting those decisions later is expensive.
• Who should write the brief — me or the contractor? The draft — you: nobody knows the business and its customers better. The final version — together: the contractor asks questions, surfaces contradictions and turns the description into a work plan with an estimate.
• What if requirements change mid-project? That’s normal — business is alive. One thing matters: the change is recorded in writing and revises the timeline or budget. Conflict is born not from the change itself but from silently expecting it to be “free.”

Checklist before sending the brief

• The goal is stated as a business outcome, not as “make a website.”
• There are 2–3 step-by-step scenarios: what a person does from entry to outcome.
• Deadlines, budget range and required integrations are specified — without them any estimate is guesswork.
• Examples and anti-examples are attached, with notes on exactly why.
• It’s clear which content exists and which is created within the project.

Lifehack: write the brief as if you’re explaining the task to a friend outside your field. If the friend gets it, the contractor will too. Jargon doesn’t make a brief more professional — it makes it more vulnerable to misreadings.