The Project That Broke My Trust in My Own Estimates

I had a system. Before every project I'd break it into phases, estimate hours for each phase, add a 20% buffer, and quote accordingly. I'd been doing this for two years. I thought I was good at it.

Then I took on a website project that proved I had no idea what I was doing.

The Quote

Five-page marketing site. Design and build. I'd done this type of project probably a dozen times. I quoted 45 hours with my usual buffer. The client accepted within an hour.

I felt good about it. Familiar work, clear scope, reasonable timeline.

What Actually Happened

The discovery call revealed they had three stakeholders with different opinions on the brand direction. Fine, I've handled that.

The content they were supposed to provide arrived two weeks late and needed significant editing before I could use it. I spent 6 hours on content I hadn't quoted for.

The design went through four rounds of feedback instead of the two in my contract, because the approval process internally wasn't my problem to manage apparently.

The build hit unexpected issues with their hosting environment that required me to find workarounds for things that should have been simple.

I finished the project in 81 hours.

I billed 45.

The Audit I Did Afterward

For the first time, I went back through a completed project and categorized every time entry.

Hours that matched original scope: 38
Hours from client-caused delays and revisions: 21
Hours from technical problems outside my control: 11
Hours I genuinely misjudged in the estimate: 11

So of the 36 hours I ate on that project, only 11 were actually my estimation error. 25 hours were things I could have flagged and billed for if I'd been paying attention.

The problem wasn't my estimation process. It was that I had no mechanism to catch scope and context changes as they happened.

What Tracking in Real Time Would Have Done

If I had been reviewing my hours weekly against my estimate, I would have seen the content editing hours spike in week one. That was the moment to say something.

By the time I noticed how far over I was, I was in the final stretch and it felt too late. Raising a billing concern after you've almost finished a project is harder. Raising it at week two when you've just documented six hours of unscoped content work is a lot more natural.

The data was there. I just wasn't looking at it during the project. I was looking at it afterward to understand the damage.

How I Changed My Process

I added a weekly check-in with myself on every active project. Takes about ten minutes.

I compare hours logged so far against my estimate. If I'm within 10%, fine, keep going. If I'm trending over, I look at why. If the reason is scope or client behavior, I document it and have the conversation.

I also changed how I write estimates. I now explicitly separate what's included and what triggers a change order. Clients get a clearer picture of what they're buying. I get a clearer line to point to when something falls outside it.

Estimates Are Not Contracts

The shift I had to make was understanding that my estimate is my best guess based on what I know at the time. It is not a promise to deliver no matter what happens.

If a client changes the scope, the estimate changes. If unexpected complexity appears, we talk about it. If I misjudged something, I own that part.

But I only know which is which if I'm tracking. Without the data, everything feels like my fault because there's nothing to point to except the original number.

Trust your hours. Review them during the project, not just at the end. That one change would have saved me from writing a check to my own client with my own labor.

Track your time, bill every minute.

Time-Trak is a native Mac and Windows time tracker with a floating timer, automatic screenshots, and one-click invoicing.

Free during beta.

macOS + Windows · Floating widget · Auto screenshots