After you've broken down a project into tasks and scored them by complexity, the next step is converting those scores into actual hours. This is where most freelancers either lowball themselves or add a vague "buffer" that bears no relation to actual risk.
The difference between a defensible estimate and one that blows your deadline by 40% lives in this single stage. You need a formula that ties complexity directly to time, then adds only the buffer you can actually justify to your client.
Start with a straightforward conversion. If you've already scored your tasks on a 1–5 complexity scale (1 = straightforward, 5 = research-heavy or technically novel), your base hours per task follow a pattern:
Pick a baseline speed that reflects your own capacity. If you know you build a standard form in two hours, that's Complexity 2. Everything else scales from there. Don't make this up; use one real project as your anchor point, then build the scale backward and forward.
Write down your anchor task and hours. You'll reference it every time you estimate. This stops you from drifting.
A buffer isn't padding. It's a percentage that covers scope creep, integration surprises, and client feedback cycles. Most freelancers add 20% and call it done. That fails because risk varies by task type.
Split your buffer into two categories:
Task risk: Does the task involve unknowns? New tools? Third-party APIs? Tight integration with legacy code? Add 10–15% per unknown variable. A straightforward CSS update gets 0%. A Stripe integration into a custom payment flow gets 20%.
Client risk: Has this client changed requirements before? Do they do slow feedback cycles? Do they ask for design revisions after code is done? Add 10–20% once, at the project level, not per task. This compounds less if you're clear upfront about revision rounds (one round included, $X per additional).
Your formula becomes: (base hours per task × (1 + task risk %)) + (total project hours × client risk %).
Example: A Complexity 3 form integration task (base: 3 hours) with a new payment gateway (15% task risk) and a client with a track record of one revision cycle (10% client risk on a 20-hour project):
3 × (1 + 0.15) = 3.45 hours for the task
20 × 0.10 = 2 extra hours for the project
Total: 3.45 + 2 = 5.45 hours
You now have a number you can defend. You know why it's not 3 hours, and you know why it's not 8.
They estimate in a vacuum, then add a blanket 30–50% buffer because the previous project ran over. This creates a disconnect: your Complexity 3 task and your Complexity 4 task both end up with the same 40% padding, even though the risks are different.
The second mistake: they let the client set the buffer. "How long will this take?" → "I'm not sure, maybe 40 hours?" → Client decides it's actually 25 hours. You just agreed to underbid yourself before you even estimated.
The third mistake: they don't write down their buffer logic. When a task actually runs over, they have no record of why they buffered it (or didn't), so the next estimate is guesswork again.
Before you lock it in, run three sanity checks:
Check 1: Recount the tasks. Did you actually break down every requirement, or did you gloss over something that sounds simple but isn't? Go back through the brief. If you see a task that touches three different systems, and you scored it Complexity 2, re-score it.
Check 2: Compare to a similar project. If you've done a similar project, what was the ratio of estimated to actual hours? If you always run 20% over on integrations, adjust future integration estimates up by that 20% as a buffer, not as a surprise.
Check 3: Challenge your base hours. For each major task, ask yourself: "Could I do this in half the time?" If the honest answer is "only if everything goes perfectly," your base hours are probably right. If the answer is "easily," you've padded the base, and you should reduce it instead of relying on a buffer to cover a soft estimate.
A solid estimate should feel tight but not panicked. If you're confident you can finish in 18 hours but you estimated 20, something's wrong—either your base hours are loose or your buffer is too large.
Write down three columns for every project: Task, Base Hours, Buffer Applied, Total. Keep this sheet. In six months, compare what you estimated against what you actually logged. You'll spot patterns: you're slow on API integrations (increase that buffer), you're fast on design systems (reduce it), your client feedback loops run two weeks longer than expected (increase client risk %).
This iteration is the only way to move from guessing to estimating. Each project refines your formula. Each estimate you track proves your next one is more defensible.