What I learned from working with my first client

"Then I added a little padding time because everything always takes longer than expected."

If you are implementing something which is almost exactly like something you personally have implemented before, then your estimate will be almost exact because you should have tracked how much time you spent on the original ... and assuming that too was a re-implementation of something you'd already done the R&D on. IOW, this is at least your third time.

If you are implementing something for which you have references that are very close to what you are building (but you didn't build it) and you already understand them, then you can make a reasonable estimate of the time to implement. In this case the OP's advice works .... add some padding. The more granular your breakdown of the problem, the better you estimate will be.

But when there is R&D on the problem, you are not talking about 'padding', but 'factors'. If you are doing something that is new to you, but you think you have (or can find) decent references, then you can estimate based on how you hope it will go (based on your breakdown of the problem), and multiply by 2.

If you can't find references, then factors of 3 or 4 beyond your ideal development scenario will be more realistic.

It's worth noting that if you are in the last scenario, then you probably weren't a good choice for the project. Also, 'agile' pricing would be better, but either fixed pricing or giving clients some idea of what to budget is more typical.

Like many things, knowing what you're worth (how much you should charge) and estimating project time take practice. The more you do it, the better you get (hopefully).

> You suck at estimating!

Took me a while to learn that one, but it's so true.