"It's 90% done" almost always means the visible work is finished and the invisible work has not started. The screens exist, the happy path runs on a developer's machine, and what remains is error handling, edge cases, real data, deployment and the things that only appear when someone who did not build it tries to use it. That remainder routinely takes longer than everything before it.
This is not usually dishonesty. Developers estimate what they can see, and the last stretch is made of things that are genuinely hard to see in advance.
Key takeaways
- The last 10% is a different kind of work: Building a feature and making it survive contact with reality are separate jobs.
- Percentages measure effort spent, not work remaining: Which is why they move so slowly near the end.
- One request settles it: Ask to use the thing yourself, on a machine that is not theirs.
- Repeated 90% is the real signal: Once is normal. Three weeks running is a scope problem nobody has named.
What is usually left when someone says 90%
The same items appear on almost every project:
| What is done | What is usually left |
|---|---|
| The screens, and the path where everything works | What happens when a field is empty, a payment fails, or two people edit at once |
| Working on test data | Working on your real data, which is messier |
| Running on a developer's machine | Running on a server, with your domain, your certificates and your accounts |
| Functionally complete | Fast enough, and still fast with a year of records in it |
| Built | Handed over: documented, deployable by someone else, monitored |
None of that is optional, and none of it is visible in a demo. This is why a project can look finished for a month.
The request that tests the claim
Ask to use it yourself. Not a walkthrough, not a screen share. A link or a build, on your own device, doing the thing a real customer or a real member of staff would do, with your own data.
The answer to that request tells you more than any report:
- You get access within a day or two. The claim is broadly true. Use it properly for an hour and note every place it stops you.
- You are offered a demo instead. Common and not necessarily bad, but note it. A demo is controlled; you want the uncontrolled version.
- It cannot be shown outside one machine. This is the important case. It usually means deployment has not been solved, and deployment is often weeks of work that nobody counted.
Why the number stops moving
Progress percentages are almost always calculated from effort spent against effort estimated. Near the end, the denominator turns out to be wrong: the remaining work was underestimated, so every day of effort adds less than a day of apparent progress. The number crawls from 90 to 92 to 93 while real work is happening, which is confusing for everyone and makes honest teams look evasive.
If you want a number that behaves better, stop asking for a percentage and ask for a count: how many items are left on the list, and how many were closed last week. Counts do not flatter and they do not stall.
When repeated 90% means something is actually wrong
Once is normal. Twice is common. The pattern to act on is the third consecutive week at roughly the same figure with no change in the list of remaining items.
That pattern usually means one of three things. The remaining work is bigger than anyone has admitted, often because a dependency does not behave as expected. Or the work is being reworked rather than finished, which shows up as the same area being touched again and again. Or the person reporting is not the person doing the work and is relaying an estimate they cannot check.
All three are recoverable, and all three get worse the longer nobody names them. The useful move is not pressure. It is to ask for the list of remaining items, in writing, with one line each, and compare it to last week's list. If the list has grown while the percentage stayed still, you have your answer.
For the wider version of this question, see how to tell if a project is really behind.
Ali Boran Gazel