Or you left the hardest part for the end. The hardest here does't necessarily mean the most difficult to figure out, it means the hardest for you -- the one you are least motivated to work on.

It could be the most boring or the least interesting. It could be lots of UI tweaks, or adding a feature you are just not very excited about. Objectively you know it should be a 4 week job, but unconsciously you drag the time along because you just seem unmotivated by your work. Conversely, the first 90% goes fast because you are motivated and put a lot more mental effort and time into.

"Coding, for a counterexample, is '90 percent finished' for half of the total coding time. Debugging is '99 percent complete' most of the time. 'Planning complete' is an event one can proclaim almost at will." -Mythical Man Month, page 154

Yes, my thoughts exactly.

My friend, you've just completed 10-30% of your work.

You now have infrastructure, support, updates, marketing, sales, pricing, subscription systems, and competition to deal with. (to name a few)

Creating the product is step 1.

My current rule of thumb is that if I don't think that I'm 90% done when I'm only 50% of the way through my schedule I'm going to miss my deadline.

My suspicion about the cause of this is that I'm conflating 'easy' with 'doesn't take long'. I think there may be some other factors to do with not wanting to admit I'll break stuff when tidying code (so not allowing time to fix it) and somehow assuming that all the little niggles that only take a couple of hours to fix will all be fixed in the same couple of hours.

I am pretty good about this. For most of my projects I keep a pretty atomic TODO list and move things into a DONE category whenever it's finished. The list grows as I come up with new things, and shrinks each time I get something done. I know I approach the finish line when I stop adding things to the list as quickly as I'm getting them off the list. This of course has nothing to do with the number of hours left, just the number of tasks.

The question rather vacuously implies he's over-estimating if by "10%" he means "10% of the time required"

I would think that the "10%" instead has to be some rough of the length of documents, the number of bugs, the number of features or some something similar. Overestimating still might be involved but there you have something to explain.