Most disappointing projects were disappointing at the brief. The seller did what the words said, and the words did not say what the buyer meant. A good brief does not need to be long. It needs to remove the guesses that cost the most when they go wrong.
Start with the outcome, not the task
"Build a dashboard" is a task. "Let account managers see which customers have not logged in for two weeks, so they can call them on Monday" is an outcome. The second version lets a good seller challenge your plan, propose something simpler, or spot that you need an export rather than a dashboard. Write the outcome in one or two sentences, then the task.
Say what already exists
List the systems the work must fit into: the framework and hosting you use, the tools your team already pays for, the brand assets that exist, the accounts the seller will need access to. Unstated constraints are the usual cause of rework, because the seller picks a reasonable default that happens to clash with your setup.
Separate must-haves from nice-to-haves
- Must have: without it the project has failed. Keep this list short enough to say aloud.
- Should have: valuable, and the first thing to drop if time or budget runs short.
- Not included: things a reader might assume are part of the work, such as content writing, ongoing support or app-store submission. Naming them prevents an awkward conversation later.
Explain how you will judge the result
Write the test you will apply when the work arrives. For software, that might be three user journeys that must work on a phone. For a design, who must be able to approve it and by what date. For content, the reader and the one action they should take. When acceptance criteria are written down, approving a milestone becomes a check instead of a negotiation.
Be honest about budget and deadline
A range is more useful than silence, and a reason is more useful than a range. "We have a fixed launch event on a known date" tells a seller which scope cuts are acceptable. If your budget is flexible only for the right solution, say that too.
Say how much AI use you are comfortable with
Some buyers want every line written by a person; others care only about the result. State your preference, and compare it with the work-mode label on each listing. The four labels are explained in the AI Disclosure Policy and in our guide to human-built and AI-assisted work.
A short template
- Outcome in one or two sentences.
- Who uses it, and what they do today instead.
- Existing systems, accounts and brand assets.
- Must-haves, should-haves and what is not included.
- How you will judge the result, and who approves it.
- Deadline, with the reason behind it, and a budget range.
- Your preference on human and AI involvement.
If writing this feels slow, that is the point: the time you spend here is time you do not spend in revision rounds. AI Project Match can also draft a first version from a rough description, which you should then correct rather than accept as written.