Why Products Look 90% Done for Months

It is almost done.

You have heard that before. You may have said it. It was almost done three weeks ago. It was almost done last month. It has been almost done for longer than the first version took to build. The feature works. The screen looks right. The team is clearly still working. Something invisible is consuming all the time.

There is a name for this. Tom Cargill at Bell Labs stated it cleanly in 1985: "The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time." The ninety-ninety rule. It is not an exaggeration. It is a description of how software actually behaves. Once you accept that, the frustration turns into preparation.

The reason the last ten percent takes so long is that it contains everything that cannot be built until everything else is built. Edge cases do not appear until the core logic is working. Performance problems do not become visible until the system is under real load. Security gaps do not surface until someone looks for them specifically. Cross-device failures only reveal themselves when you test across devices. Localization breaks that seemed minor become blocking when the release target is global. The first 90 percent is the work you planned. The last 10 percent is the work that emerges from having done the first 90 percent. You cannot skip that sequence. You can only name it.

Douglas Hofstadter named a related truth: "It always takes longer than you expect, even when you take into account Hofstadter's Law." The law is recursive. You account for the delay and it still surprises you. This is not a failure of intelligence or effort. It is a failure of imagination. We can only estimate the work we can see. The work we cannot see yet is the work that will actually determine the timeline. The best teams stop being surprised by this and start planning for it.

Kahneman and Tversky called this the planning fallacy. In a study of psychology students, participants predicted they would complete their thesis in about 34 days. On average, it took 55 and a half days. Only 30 percent finished by their own predicted date. These were graduate students. Disciplined people. The pattern holds across domains. The closer we are to something, the more optimistically we estimate it. The more invested we are in a deadline, the harder it becomes to update the estimate when reality diverges. Knowing this is the first step to breaking it.

A 2024 BCG study of large-scale technology programs found that more than two-thirds are not delivered on time, within budget, or within scope. Two-thirds. That is not a bad year for software. That is the base rate. The ninety-ninety rule is not a warning. It is the industry operating exactly as it always has. The difference between teams that get caught by it and teams that do not is whether they planned for what they could not yet see.

The last mile of a software product typically contains: all the error states nobody designed. The empty states that appear when data is missing. The loading states between one thing and the next. The accessibility requirements that were deferred. The mobile layout that behaves differently from the desktop. The performance optimization that did not matter at low traffic but matters now. The deployment pipeline that has never been run against production. The security review that surfaces three things that need to change. Each of these is a real task. None were in the original estimate. All of them are necessary. Name them before they find you.

Understanding this does not make the last 10 percent faster. But it changes everything about how the team talks about it. When a product looks 90 percent done and progress appears to stop, it is not stalling. It is entering the category of work that only becomes visible at 90 percent. That work is real. It is not poor planning. It is a structural property of building software. And once you name it that way, leadership stops treating it like a failure and starts treating it like a phase.

The teams that handle this best do two things. First, they build the last mile into the estimate from the beginning. Not as a vague buffer. As explicit line items: error states, edge cases, cross-device testing, performance, deployment, security review. When these have names and owners before the last 10 percent arrives, they do not become emergencies. Second, they signal the shift. When the team moves from building features to polishing the system, that transition is a milestone worth naming. "We are in the last mile" tells leadership that progress is happening even when the visible surface of the product looks the same.

Here is your move. The next time someone asks when a product will be done, add 30 percent to the remaining estimate and name the specific last-mile work that covers. Not because you are being pessimistic. Because you are being accurate. The team that names the invisible work makes it visible. Visible work gets resources, gets time, and gets done. You have the power to make the last 10 percent expected instead of alarming. Start by naming it today.