A freelancer who jumps straight from a client email to an hour estimate will underprice, miss scope, and resent the project before it starts. The job is to sit with the brief—email, call notes, or Slack thread—and pull out exactly what the client is asking for, what they've assumed, and what they haven't said at all.
This is Stage 1. It takes 10–15 minutes and prevents the cascading errors that make a $5k project feel like $8k of work.
You need four things from the brief:
Explicit scope: What they say they want built or done. "A landing page with three sections and a contact form."
Success criteria: How they'll know it's done right. Sometimes stated, usually not. Look for words like "fast," "professional," "complete," or mentions of where it will live.
Constraints: Budget, timeline, platform, integrations, compliance requirements, content they'll provide vs. you'll create.
Unknowns and assumptions: Gaps where they've left something unsaid. "They said mobile responsive but didn't mention tablet. They want three payment methods but only named two."
Most freelancers skip this and jump to "sounds like 40 hours." You're not doing that.
Client briefs are rarely linear. They're often a mix of history, budget anxiety, half-formed ideas, and one or two hard requirements buried in the middle.
Start by reading the brief all the way through without taking notes. Get the shape of it. Then go back and mark up:
Deliverables. What outputs do they expect? A design? Code? A report? A tool they can use? Underline every noun that refers to an end product.
Activities or features. "The site should let users upload files." "We need a dashboard showing metrics." Mark these separately from deliverables—a deliverable is the thing; a feature is what it does.
Mentions of existing systems or integrations. "It needs to talk to our Stripe account." "It has to work with the old CMS." These are scope multipliers and often mentioned in passing.
Who's doing what. Will they provide the copy, images, video? Will they review designs or just the final product? This affects your hours because writing copy is not the same as editing theirs.
Timing and versioning. Is this a one-shot or "Phase 1"? Do they expect rounds of revisions? Do they need it by a hard date?
Write these down in short phrases. You're not writing a formal scope document yet; you're building a map.
After you've marked up the brief, look for what's missing or what contradicts itself.
Vague success criteria. "Professional looking" and "modern" are not specifications. You need to know what they mean: pixel-perfect mockup match? Industry-standard appearance? Specific color palette? Ask in your proposal email.
No mention of revisions or approval loops. If they've said nothing about design rounds or stakeholder review, you're either assuming unlimited revisions or they're assuming you'll get it right the first time. Mark that as an assumption to clarify.
Unclear ownership of content or decisions. "The site should showcase our team." Do they have team photos? A bio document? Or will they send you whatever they find on their old site and expect you to clean it up? These are hours, and they matter.
No explicit testing or browser/device scope. They said "mobile responsive" but do they mean iPhone 12 and up? Safari on iPad? Android tablets? Or just "looks okay on a phone"? Write down your assumption.
Integrations mentioned without detail. "It connects to our payment processor." Which one? Do you need API docs? Sandbox access? How will you test it? Mark these as questions.
Assuming their language is precise. When a client says "fast," they might mean "loads in under 2 seconds on LTE" or "doesn't feel sluggish." You need the specific version. Your brief extraction is the place to note that you don't have one yet.
Filling in gaps with best-guess features. "They probably want a blog. I'll add that to scope." No. You write down what they said and what they didn't say. The second is your negotiation point, not hidden scope you'll discover mid-project.
Ignoring the tone or implied constraints. A brief that opens with "This is urgent" followed by "we have a $2k budget" is telling you something. Budget and timeline are always in tension. Write down both so you don't estimate in a vacuum.
Treating vague scope as simpler. "Just a simple login page" is not simpler than a detailed spec. Vagueness means you'll argue about what "simple" meant. Mark it as a clarification needed.
Before you move to estimation, ask yourself:
If you can't say yes to all five, go back and extract more. Or make a list of clarifying questions and ask the client before you estimate.
The extracted scope becomes your input for Stage 2—task decomposition and complexity scoring. You won't estimate hours on a vague brief. You'll estimate hours on a scope you can describe, because then your estimate doesn't move when the client changes their mind about what they wanted.
Extract first. Estimate second. This one step saves arguments and keeps you profitable.