How to Estimate Hours Without Lying to Yourself
The estimate is wrong before you write it down, and it is wrong in a direction you would never choose on purpose: low. Not because you are dishonest, but because of how the number gets built. You picture the work you know how to do — the research, the draft, the build — and you price that picture. What you actually get paid for is everything around it.
This note is about the arithmetic that makes an estimate survivable. None of it needs software. One of the three habits below is enough to stop the pattern; all three make it boring.
The work you forget is work
Every estimate starts by counting the visible middle. Here is the same project priced twice, honestly:
| The middle you count | The edges you usually forget |
|---|---|
| Interviews, analysis, the deliverable itself | The kickoff call and the two emails that set it up |
| Reviewing material the client sends late | |
| One round of revisions — the one you always do | |
| Waiting for approval you cannot bill | |
| Writing the handover note nobody asked for | |
| The second conversation after delivery |
The edges are not surprises. They happen on nearly every project. If they happen every time, they are the work, and an estimate that excludes them is not optimistic — it is just incomplete.
The fix is mechanical: before you commit to a number, write down the six lines above and put a half-day figure next to each one. Do not refine them. Half-days are precise enough, and they stop the fake precision that makes an estimate feel researched when it is only detailed.
Estimate in half-days, price in money
Hours invite a lie of a specific kind: 6 hours sounds small, and small numbers get rounded down. Half-days are harder to round. Four half-days is two days, and two days is a thing a client can picture.
So build the estimate in half-day blocks:
- The middle: how many half-days of real attention does the deliverable take?
- The edges: from the table above, how many half-days?
- The buffer: one half-day per two weeks of calendar time, or one per project if it is short.
That last line is the one people delete to stay competitive. Deleting it does not lower the cost of the project; it moves the cost from the invoice to your evenings. A quote with no buffer is a quote that has already spent the money.
Convert to a price at the end, not the beginning. If you start from a price the client will accept, you will reverse-engineer an hours figure to fit it, and the figure will not survive contact with the work.
Three questions that catch a bad estimate
Before the number leaves your desk, ask:
- What part of this have I never done before? Anything new takes roughly twice as long as the part you know. Price the unfamiliarity, not the optimism.
- Who else has to act, and how fast do they act? A project with three approvers is a project with three waiting rooms. Waiting is calendar time; if the calendar time blocks other work, it is your cost.
- What did the last similar project actually take? Not what you quoted — what it took. If you do not have that number, that is the real problem, and it is the next section.
Two of the three can be answered in ten minutes. They catch most of the gap between quoted and actual.
Keep the number you are missing
You cannot improve an estimate you never compare to anything. The minimum viable record is one line per project:
` quoted hours | actual hours | the half-day block that blew up `
Three projects of that is enough to see your own pattern, and the pattern is usually consistent: the same phase goes over every time. Most people find it is either client review or revisions — both of which are in the edges table, both of which they keep leaving out.
Write the line the week the project closes, not later. Later means never, and never means the next estimate is built the same way as the last one.
When you are already wrong
You will sometimes be half-way through and know the estimate was fiction. Two things matter then, and neither is apologising:
Say it early. The cost of a scope conversation rises with every week you delay it. Told at week two, it is a scheduling problem. Told at delivery, it is a bill.
Bring a choice, not a confession. "The discovery took longer than I priced — there were two data sources we did not know about. I can finish the full scope for X, or cut the second source and hold the original number. Which is more useful?" That is a decision the client can make. "I underestimated" is not.
No discount is required. Undershooting an estimate is a pricing problem, and pricing problems are not solved by working for free — they are solved by pricing the next one properly. Absorbing it silently teaches the client that your numbers are negotiable, and teaches you that the arithmetic does not matter.
The one-line version
Count the edges, estimate in half-days, keep the buffer, and record what actually happened. Do that for three projects and estimating stops being a personality trait and becomes a procedure.
Which is the point. An estimate is not a prediction about the future; it is a description of the work you have agreed to do. Make the description complete and the number stops surprising you.
Related notes
- Define Done Before You Start, or Argue About It Later — an estimate is only as good as the boundary it is estimating against.
- Four Numbers Every Freelance Tracker Should Calculate — where actual hours come from, and what to compute with them.
- Scope Doesn't Creep. It Gets Invited. — the other half of why projects run over.