There’s an old engineering joke that the first ninety percent of a project takes ninety percent of the time, and the last ten percent takes the other ninety percent. It gets repeated as a wry observation, but it’s really a precise account of a specific failure: the thing that feels almost done is nowhere near done, and the gap between those two states is where schedules quietly detonate. Understanding why is more useful than laughing at it, because the mechanism is the same every time.

What “ninety percent done” usually means is that the interesting part works. The feature does the thing it was supposed to do, on the inputs you had in mind, in the environment you were testing in. That’s the part you pictured when you estimated, because it’s the part that’s conceptually the point — and it’s genuinely most of the thinking. But it’s not most of the work, and the difference is the entire second ninety percent: the empty states, the error handling, the input that’s malformed in a way you didn’t anticipate, the loading spinner, the migration for existing data, the thing that breaks only when two users do it at once. None of it is glamorous. All of it is required before anyone can actually use what you built.

The reason this consistently escapes estimates is that the finishing work is invisible from the front. When you picture a task, you picture it working — you don’t picture the twelve ways it can fail, because enumerating failure modes is itself part of the work you haven’t done yet. So the estimate covers the part you can see, which is the happy path, and the part you can’t see is precisely the part that turns out to be most of the effort. It’s the same asymmetry that makes estimates a distribution with a long right tail: the unknowns only add time, and a huge share of them live in the unglamorous tail of finishing.

This also explains a demo that lies. A thing can be genuinely impressive in a demo and months from shipping, because a demo exercises exactly the ninety percent that was easy — the curated input, the happy path, the controlled setting — and none of the second ninety percent that makes it survive contact with real users. “It basically works” and “it’s basically done” sound alike and mean wildly different things. The first is a statement about the demo; the second is a claim about all the finishing, and the finishing is the part nobody has looked at yet when the words “basically done” get said.

The practical response isn’t to pad estimates by some ritual multiplier — it’s to make the second ninety percent visible before committing, so it can be estimated instead of discovered. Ask, of a task that feels nearly scoped, what happens on the empty input, the huge input, the concurrent access, the partial failure; what the migration and the rollback look like; what “done” actually requires beyond the happy path. Those questions drag the invisible work into view, where it becomes something you can plan around rather than something that ambushes you at the end. The finishing is not a small remainder after the real work. Very often it is the real work — and the projects that ship on time are the ones that estimated it as such from the start.