The 80/20 Rule of "Almost Done"

I shipped a feature last week that I thought was basically finished on Tuesday. It had all the main functionality, the UI worked, and the happy path test passed.

Then came the real work.

Error handling. Edge cases. Mobile responsiveness. Documentation. Edge cases I hadn't considered. A client who wanted it to feel "faster" even though it was already performant. That's when it hit me again: the final 20% of any project isn't 20% of the effort. It's closer to 80%.

This isn't a new lesson for me. I've learned it half a dozen times. But I keep forgetting it when I start something new. There's something optimistic about the human brain when it comes to finishing—maybe it's the dopamine hit of seeing something work. Once the main thing works, my brain insists we're done.

The weird part? The 20% is usually where the actual value lives. The polish, the error messages nobody reads until they're frustrated, the onboarding that makes the difference between "cool tool" and "this is how we do things here."

I've started calling something "feature complete" way earlier than I should. Now I'm trying a different question: "What would I need to do to make this embarrassingly good?" That shift alone has changed how I think about what to build next.

Anyone else have a mental trick to fight the "almost done" delusion?