How to estimate project hours without guessing

Every freelancer underestimates. It is not a character flaw, it is a well documented cognitive pattern: we estimate the version of the project where nothing unexpected happens, and no project has ever been that version.

The good news is that the error is systematic, which means it is correctable.

Why estimates are low

• You estimate the happy path. No feedback delays, no third party surprises, no rework.
• You forget the surrounding work. Calls, emails, revisions, handover, invoicing. Real hours consumed by the project that never appear in the estimate.
• You remember your best day. The reference point is the day you were fast and uninterrupted, not the average day.
• You want the project. Optimism is contaminated by wanting the answer to be a number the client will accept.

Decompose, then sum

The most reliable single fix. Break the project into pieces small enough that you can name a number for each without thinking hard, then add them up. Anything you cannot estimate confidently is still too big, so split it further.

Two things happen. Individual small estimates are more accurate than one large one, and the decomposition itself surfaces work you had not thought about, which is where most of the missing hours were hiding.

Add the invisible categories explicitly

Put these as line items in your estimate, not as a mental cushion:

• Kickoff and discovery
• Client communication through the project
• Revisions, at the number you actually agreed
• Review and quality checking
• Handover, documentation, and delivery
• Project admin, including invoicing

For most freelance projects these total 20 to 35 percent of the production hours. Estimating them at zero is the second largest source of error after decomposition.

Apply a contingency, and be honest about what it is

Add 20 to 30 percent for unknowns. This is not padding to be embarrassed about, it is a reserve for the things that have happened on every previous project and will happen on this one. Familiar work sits at the low end, unfamiliar work at the high end, and anything involving a third party system you do not control deserves more.

If you finish under, you keep the margin on a fixed fee and you bill less on an hourly one. Both outcomes are good.

Use ranges internally, a single number externally

Estimate as a range because that is what you actually know. Present a single number, because clients cannot approve a range and will hear the bottom of it anyway.

For a fixed fee, price the top of the range. For hourly, quote the midpoint with a written note about what would push it higher.

Build the dataset

Estimation improves through recorded outcomes, not through effort. For every project, record the estimate, the actual hours, and the ratio. After five projects you will see your personal multiplier, and it will be remarkably stable, usually somewhere between 1.3 and 1.8.

Apply it. If you consistently run at 1.5, then a 40 hour estimate is a 60 hour project and pricing it as 40 is a choice to lose money.

This requires tracking hours even on fixed fee work, which is exactly why Timely is built around project budgets and shows logged hours against the estimate as the project runs.

Watch the burn while the project is live

An estimate is only half the value. The other half is noticing at 60 percent of the budget that you are 40 percent through the work, while there is still time to have a conversation about scope. A budget you check at the end is a post mortem. A budget you check weekly is a control.

TL;DR

• Decompose into pieces small enough to estimate confidently, then sum.
• Add explicit line items for communication, revisions, review, handover, and admin. Usually 20 to 35 percent.
• Add 20 to 30 percent contingency, estimate as a range, present a single number.
• Record estimate versus actual on every project. Your personal multiplier is stable and usable after about five.