If you send three developers a one-line description and get back three wildly different prices, the brief is usually the reason — not the developers. Quoting is risk pricing: the less someone knows, the more padding they add, and the less comparable the numbers become. A good brief costs you an hour and reliably saves more than that. You don't need technical language to write one; you need to be specific about outcomes.
Why vague briefs cost you money
Consider "I need my product page improved." A developer reading that has to price for the worst plausible interpretation — maybe it's a redesign, maybe it's a new gallery, maybe an integration is involved. So the quote is high and hedged. Meanwhile a second developer assumes the smallest version, quotes low, and discovers the truth mid-build. Now you're comparing two numbers that describe two different projects, and the "cheap" one turns into a change-request negotiation.
You're not writing a specification for a developer to follow blindly. You're removing the uncertainty that makes them guess — and guessing always gets priced in your direction.
What to include
1. Context: who you are and what the store does
Two or three sentences. What you sell, roughly how big the catalogue is, whether you're on Shopify or moving to it, which plan if you know it. This tells a developer whether native features cover your case or whether you're in Plus territory.
2. The problem, in business terms
Describe what's wrong or missing from your side of the counter, not the fix you've imagined. "Customers abandon at the shipping step and we think the options are confusing" is far more useful than "add a shipping calculator app." The first invites a diagnosis; the second buys a solution you may not need.
3. The outcome you want
What does done look like? Ideally something observable: customers can order in bulk from one screen; stock in Shopify matches the warehouse within fifteen minutes; the product page loads in under two seconds on mobile. Measurable outcomes stop "finished" from being a matter of opinion.
4. What you already have
List the relevant furniture: your theme (bought or custom), the apps involved, any other systems in play — accounting, ERP, 3PL, CRM — and whether they have an API. Also mention previous work on the same area; inherited code changes the estimate substantially. If a previous developer built something custom here, say so.
5. Constraints
Deadlines and why they exist, budget range, things that mustn't change, people who need to approve. A real deadline ("our peak season starts 1 November") lets a developer tell you honestly whether it's possible. A fake one just raises the price.
6. Budget — yes, share it
Merchants withhold budget fearing they'll be charged up to it. In practice the cost is worse: without a range, you get proposals aimed at the wrong scale entirely, and waste everyone's time. A range like "we're thinking £3–5k, tell us if that's unrealistic" gets you an honest answer and a scope that fits. A good developer will tell you when your number is too low or more than you need.
7. What's explicitly out of scope
Optional, but it's the line that prevents the most arguments. "We're not redesigning the brand" or "content migration is our job" removes whole categories of assumption.
A structure you can copy
- About us: what we sell, catalogue size, platform and plan.
- The problem: what's happening now, and how we know it's a problem.
- Desired outcome: what "working" looks like, measurably if possible.
- Current setup: theme, relevant apps, other systems, prior custom work.
- Constraints: deadline and why, budget range, non-negotiables.
- Out of scope: what we're not asking for.
- Practicalities: who decides, how to reach us, when we can give access.
Half a page to a page is plenty. Longer isn't better — clearer is.
Things worth attaching
A link to the store, obviously. Then: screenshots with arrows pointing at the problem (enormously effective), a short screen recording if the issue is behavioural, examples of other stores doing what you want, and documentation links for any third-party system involved. Two minutes of screen recording routinely replaces a twenty-message email thread.
What to expect back
A good response to a good brief includes follow-up questions — that's a positive signal, not a failure of your brief. What you're looking for is a written scope that reflects what you actually asked for, a price and timeline, named risks, and clarity on exclusions. If a developer quotes a substantial project from a paragraph without asking anything, be careful: they've either done it a hundred times or they haven't understood it.
Bottom line
Describe the problem in business terms, define the outcome, disclose your setup and constraints, and share a budget range. It takes an hour, it gets you comparable quotes, and it dramatically reduces the odds of the mid-project conversation that starts "I assumed that wasn't included."