Estimate Time Properly
When you talk to potential clients, it’s pretty seldom that one will say, “It doesn’t matter how much it costs, let’s get going.” Most want an estimate. I wrote about determining my prices in a previous post, but since most of us work on some hourly rate, we need to figure out how long it will take so we can give a proper estimate.
The number one thing you don’t want to do is underestimate; you will run into 1 of 2 problems that way: you will stick to your word on the estimate and lose money because you don’t want to change the price you gave the client, or you do change the price on the client and they get upset with you for increasing their costs. This could hurt the credibility and trust they have in you. So we need a way to properly estimate time.
At first it’s going to be a lot of trial and error. Keep time on all projects you do, not just paid ones. That way you can get a feel for how long it takes you to do something. There are also two questions you should ask yourself:
- “Have I done something similar before?” Chances are you’ll do it faster the second time around.
- “Have I never done anything like this before?” On the flip side, there might be a learning curve to account for.
Once you’ve tracked time on a few projects you’ll probably have a good feel of how you work. As for me, I always initially underestimate how long something will take it (I feel like most programmers do), so I will take the number of hours I think a project will take and multiply it by 1.5. That number accounts for any unforeseen problems and tasks that take a bit longer than expected. Of course, this number is different for everyone.
Do you have a different way of estimating time that works for you? Leave it in the comments!





I like this article. Very straightfoward.
The x1.5 “formula” is very good. I just take the number of hours by previous projects and add a few more considering problems (they always come..)
The learning curve is the harder one to estimate though.
Marco- Thanks! And agreed. The learning curve is a tough one. Looking to previous projects is a good idea- I even think in some cases if you do similar projects enough, you can standardize a price per project.