Why Bad Briefs Are So Expensive
A vague brief doesn't just slow down development. It causes:
- Developer builds the wrong thing
- Client is disappointed
- Arguments about what was agreed
- Additional time and money to rebuild
- Bad blood that makes future work harder
A good brief prevents all of this. And you don't need to be technical to write one. You need to be specific.
The Structure That Works
1. What's the context?
Give the developer a picture of what you have and who uses it.
"We have a WooCommerce store selling cosmetics in Ukraine. About 200 orders per month. 80% of customers are on mobile. We use Nova Poshta for delivery and Liqpay for payment."
This one paragraph tells the developer your tech stack, scale, audience, and integrations. It will save hours of back-and-forth.
2. What's the specific problem?
Describe exactly what's broken or missing. Include:
- What you see happening
- What you expected to happen instead
- When it started (if it's a bug)
Bad: "The checkout doesn't work."
Good: "When a customer selects Nova Poshta delivery and tries to proceed to payment, they get a white screen instead of the payment page. This started after we updated WooCommerce on March 15th. Happens on all devices we tested."
3. What does success look like?
How will you know the work is done? Be explicit.
"Customers can select Nova Poshta city and branch, proceed to Liqpay payment, and receive order confirmation email. Tested on iPhone and desktop Chrome."
This becomes your acceptance criteria. When this works — the project is done.
4. What are the constraints?
- Deadline: is there one? Why?
- Budget: what's your range?
- Access: can you provide admin access, hosting credentials, FTP?
- Platform: WordPress, custom code, something else?
- Existing integrations that must keep working?
5. What should NOT change?
Often more important than what should change. "The overall design must stay the same. We only want to fix the checkout — nothing else should be touched."
Developers who don't know what's off-limits sometimes "improve" things you didn't want improved.
A Complete Example
Here's what a good brief actually looks like:
We have a WooCommerce store at [url]. It sells handmade ceramics, about 50 orders/month.
Problem: The "Add to Cart" button on individual product pages doesn't work on iPhone. When you tap it, nothing happens — the cart count doesn't change and no confirmation appears. Works fine on desktop.
This started around 2 weeks ago — we updated a few plugins around that time.
Success criteria: Tapping "Add to Cart" on any product page on iPhone (tested on iPhone 12 and 13, iOS 16+, Safari and Chrome) adds the item to cart and shows cart count update.
Please don't change any other part of the site. Specifically: keep all prices, product photos, and shipping settings as they are.
Deadline: Would like this fixed before the weekend if possible (orders have dropped since this broke).
Budget: Up to $150 for this fix. Can provide admin access and hosting credentials.
Notice what this brief does: it gives context, describes the exact problem, explains when it started, defines success, sets boundaries, mentions deadline and budget. A developer reading this knows exactly what's needed.
What You Don't Need to Include
You don't need to suggest a technical solution. "I think it might be a JavaScript conflict" or "maybe you need to reinstall WooCommerce" — leave that to the developer. Your job is to describe the problem and the expected result. Their job is to figure out how to get there.
You also don't need to write an essay. The example above is 200 words. That's plenty.
The One-Question Shortcut
If you're not sure whether your brief is specific enough, ask yourself:
"Could two different developers read this and build the same thing?"
If the answer is no — there's ambiguity somewhere. Find it and clarify it before you hand it over.
That question has saved me — and clients — more arguments than anything else.