Why most briefs get bad replies
A developer reading a brief is doing one thing: pricing risk. Vague briefs mean high risk, and high risk gets priced in — or priced out. The briefs that get fast, specific, cheap-to-evaluate replies are the ones that answer the six questions below before they are asked.
The six questions
1. What does success look like in business terms?
Not "a modern website" — that describes every website. "Generate 30 qualified leads a month for our accounting firm" is a target an entire build can be shaped around. If you cannot state the business goal, the project will optimise for decoration, because that is what is left.
2. What exactly needs to exist?
Page list, feature list, integrations. Rough is fine; complete is essential. "Shop with about 200 products, 3 product types, wholesale login" prices in an afternoon. "Ecommerce site" prices in a week of back-and-forth — or worse, a guess.
3. What are you locked into?
Platform, hosting, existing tools, brand systems, deadlines, budget band. Constraints are not weaknesses; they are the difference between a quote and a conversation. Especially the budget band — stating it gets you dramatically more replies, because developers skip the briefs they cannot price.
4. Who does what?
Who writes copy? Who sources images? Who enters products? Who approves design? The answers change the quote more than most technical decisions. "You handle everything" and "we handle content" are both fine answers — they are just different prices.
5. What exists already?
Current site, analytics access, previous attempts, the developer who vanished. History explains present constraints, and honest history gets honest quotes.
6. When does this need to be live — really?
The real deadline, including what happens if it slips. "ASAP" means nothing and invites nothing. "Live before our October trade show, hard constraint" means every quote you get includes a real plan.
The template
Project: one sentence.
Goal: the business outcome.
Scope: pages / features / integrations, as a list.
Constraints: platform, tools, brand, deadline.
Budget band: a range you can actually spend.
Content: who produces what.
Existing: links, access, history.
Timeline: real deadline and why.
Eight lines. A developer can quote it in one pass, and you can compare the replies on substance instead of vibes.
What not to do
- Do not request "something like [competitor site]" without saying which parts. You will get their whole site — including their mistakes — at custom prices.
- Do not hide the budget to "see real prices." You will see real prices for a project that is not yours.
- Do not specify the solution before stating the problem. "We need React" is a symptom. The brief that says what the site must achieve gets better technology decisions than the one that dictates them.
Ready to skip the template? The brief form here asks these six questions in order — and you get a scoped quote back within two business days.