Why freelance project estimates are always wrong (and how to fix them)

The estimate you gave at the start of the project is almost always wrong.

Not because you’re bad at estimating. Because everyone is bad at estimating. Decades of software research confirm it: humans systematically underestimate how long tasks take, by an average of 30 to 50%. This is called the planning fallacy, and it applies to freelancers, engineers, architects, and surgeons equally.

The freelancer’s version: you quote 20 hours, you spend 28. You quote 3 weeks, you deliver in 5. Each project, individually, feels like a specific exception. Collectively, it’s a systematic bias.

Why the bias persists

You’re estimating the ideal path. Your estimate assumes no blockers, clear feedback, first-draft approvals. Real projects don’t unfold that way. They have waiting time, revision rounds, clarifications, unexpected complexity. The gap between ideal-path estimate and actual-path delivery is roughly what you lose.

You forget overhead. A 20-hour project doesn’t take 20 hours. It takes 20 hours of direct work plus emails, calls, project coordination, and the mental load of context-switching. For many projects, overhead is 30 to 40% of the total.

You remember your best projects. When you estimate, you anchor on similar past projects — but you anchor on the ones that went smoothly, not the ones that ran three weeks over. Memory is not a random sample.

How historical data fixes this

The only reliable antidote to optimistic estimation is historical data on your own past projects.

If you’ve tracked actual hours on 15 logo design projects and the range is 12 to 32 hours with a median of 21, your next logo design estimate should start from 21 hours, not from the ideal-case scenario.

This is why tagging calendar events by project matters beyond billing. It builds the database you need to estimate accurately. After a year of tracked data, your estimates are calibrated to your actual pace, your actual clients, and your actual work style — not a theoretical average.

The buffer rule

If you don’t have historical data yet, the practical fix is a systematic buffer.

For most freelance project types, a 30% buffer on top of your best-case estimate puts you close to the median outcome. A 50% buffer puts you close to the 75th percentile — meaning most projects will come in under that estimate.

Quote the buffered number. If the project comes in under, you’ve delivered faster than expected. If it comes in over, you’re close to what you actually quoted. Either outcome is better than the un-buffered version.

What to do when a project runs over anyway

Even with good estimates, some projects exceed scope. Here’s the process.

Identify the cause early. Is the overrun because the scope changed, the brief was unclear, or your estimate was simply wrong? The answer determines what to do next.

Scope changes get a change order. If the client added deliverables, changed direction, or expanded the brief, that’s additional work and it gets additional billing. A simple written record of the change and the rate is sufficient. Most clients accept this when it’s documented clearly and raised promptly, not at the end of the project.

Estimation errors are your cost — this time. If the scope didn’t change and you underestimated, absorb it. Then update your estimate template so you don’t repeat the same error.

Brief-clarity failures need a conversation. If the project ran over because the initial brief was ambiguous, that’s a process problem. Future projects with this client should start with a more detailed brief, or include a discovery phase as a separate billable item.

Fixed-price vs. hourly: the estimation stake

For fixed-price projects, the estimation error is entirely yours. You quoted €3,000 for a website. It took 40 hours instead of 20. Your effective rate dropped in half. The full mechanics of how to price a fixed-fee project — including buffer rules and risk multipliers — are worth reading alongside this.

For hourly projects, scope expansion is automatically compensated — but clients can push back on growing invoices.

The hybrid that works for projects with variable scope: a fixed price for a defined scope, with a clearly stated hourly rate for any work beyond that scope. Both parties know what’s included and what expansion costs. The client controls the scope; you control the rate.

Whatever model you use, your estimate accuracy is directly measurable. Quoted hours versus actual hours, project by project. That variance, tracked over time, is the data that makes the next estimate better.

Timescanner logs your actual hours per project from your calendar, letting you build the historical dataset that makes your estimates accurate. Works with any iCal-compatible calendar.