"I need a website, how much would that cost" is a question almost impossible to answer honestly, not because developers are evasive, but because that sentence alone doesn't contain enough information to price anything accurately. A well-written brief fixes this, and it takes less time to write than most people assume.
Why a Vague Brief Actually Costs You More
A developer quoting a vague request has two options, neither good for you. Quote high to cover the unknown risk of scope turning out bigger than expected, or quote low based on an optimistic guess and renegotiate once the real scope becomes clear mid-project, which tends to create friction and delay. A specific brief removes the guesswork on both sides, and specific, well-scoped projects consistently get more accurate, often lower, quotes than vague ones.
Start With the Actual Goal, Not the Feature List
Before listing pages or features, state what the site actually needs to accomplish. Generate leads for a service business. Sell a specific product. Give existing customers a place to manage their account. This single sentence shapes everything else, and skipping it means a developer is scoping blind, guessing at priorities you haven't actually stated.
List Every Page You Actually Need, By Name
Not "a few pages," an actual list. Home, About, Services (and how many distinct services need their own page versus one shared page), Pricing, Contact, Blog if applicable. A specific page count is one of the single biggest factors in scoping accurately, and it's something you already know without needing any technical knowledge to specify.
Describe Any Functionality Beyond Static Content
This is where vague briefs cost the most. "I need a contact form" is simple. "I need users to create accounts, log in, and see their own order history" is an entirely different category of project, genuinely custom software, not a content site. Being specific here, even in plain, non-technical language, is what separates an accurate quote from a wildly wrong one.
Worth specifying explicitly: does anyone need to log in, does the site need to store or display data specific to individual users, are there any payments involved, does anything need to connect to another tool you already use, email marketing, a CRM, a booking system.
Bring Actual Examples of Sites You Like
"Modern and clean" means something different to every single person who says it. Three or four real websites you genuinely like, with a sentence on what specifically you like about each one, communicate far more accurately than any adjective could. This isn't about copying another site, it's about giving a developer a real, shared reference point instead of guessing at your taste from a vague description.
Be Honest About Your Timeline and Budget Range
A real budget range, even an approximate one, helps a developer propose something that actually fits, rather than either underselling what's possible within your budget or scoping something you can't actually afford before you've even had a real conversation. The same applies to timeline, a genuine hard deadline (an event, a launch date) changes what's realistically achievable and is worth stating upfront rather than discovering mid-project.
List What You Already Have
Existing content, copy already written, product photos, a logo and brand colors, previous site analytics, anything you already have ready shortens the actual project and should genuinely lower the cost, since content creation from scratch is real, separate work. Listing what exists, even roughly, gives a much more accurate picture than assuming a developer will guess what's already available.
A Simple Brief Template
Goal: what should this site accomplish, in one or two sentences.
Pages: a specific list, by name.
Functionality: anything beyond static content, logins, payments, integrations, stated in plain language.
Design references: three or four sites you like, and specifically why.
Budget range: even an approximate range.
Timeline: any real, hard deadlines.
What you already have: existing content, brand assets, previous analytics.
This takes maybe twenty minutes to put together and consistently produces faster, more accurate quotes than a vague "I need a website" message, since the developer isn't spending the first several conversations just extracting the same information through back-and-forth questions.
What This Actually Signals to a Developer
A specific, well-thought-out brief also communicates something beyond just the project details, it signals that you've genuinely thought through what you need, which tends to get taken seriously and prioritized over a vague inquiry that reads like the person hasn't actually decided what they want yet. It's a small amount of upfront effort that pays off in both a more accurate quote and a smoother working relationship once the project starts.
Frequently Asked Questions
What if I don't know the technical details of what I need? That's completely normal and expected, the brief template above is intentionally written in plain language, not technical terms. Describing what should happen, "customers should be able to book a time slot," is enough, the technical implementation is the developer's job to figure out, not yours to specify.
Should I get quotes from multiple developers before deciding? Generally yes, and a specific, consistent brief sent to each one makes the resulting quotes genuinely comparable, rather than comparing wildly different numbers based on each developer interpreting a vague description differently.
How detailed does the design reference section actually need to be? Three or four real site examples with a sentence on what you specifically like about each, layout, color scheme, tone, imagery, is usually enough to communicate real direction. It doesn't need to be exhaustive, it needs to be specific enough that two different people reading it would picture something similar.
If you're putting together a brief for a real project and want a second pair of eyes before sending it out for quotes, I'm happy to take a look.
Get in touch: https://pixelanas.com/contact
Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751