The myth of the 90% done software project

There is a sentence we hear often in sales meetings: "the system is 90% done, just a few details left". It usually comes from companies that built a project with a freelancer or another software house, watched the money run out or the vendor disappear, and are now looking for someone to cross the finish line.

The conversation that follows is almost never the one the client expects. After more than 8 years and hundreds of projects evaluated, we've learned that those supposed remaining 10% can take as long as, or even longer than, everything built so far.

This post explains why. Not to discourage anyone, but because understanding this phenomenon is what separates a project that finally goes live from an endless cycle of "almost there".

What gets called a detail is where the work lives

In our experience, the perception of progress in software is misleading. The screens exist, the main flows navigate, the demo runs beautifully in the meeting. To the eyes of whoever is paying, that's 90%.

But what's missing is rarely screen volume. What's missing is what never shows up in a demo: error handling, data validation, behavior on poor connections, integrations that respond in unexpected ways, permissions, edge cases, performance with real data at real volume. Each of these items looks like a detail. Added up, they are usually the largest share of engineering hours in any serious system.

That's why the "only 10% left" estimate is almost always wrong: it measures what can be seen, and the cost sits in what can't.

Where it bites: testing and real-world usability

Making something work in a contained environment is infinitely easier than in a real one. In the contained environment, the person operating the system is the person who built it, following the happy path they designed themselves. In the real world, users don't behave the way you expect.

They fill out the form in the wrong order. They paste text with broken formatting. They use the system on a phone while standing in line at the bank, with an unstable connection. They double-click the pay button. They leave a session open for three days and come back expecting everything to still work.

None of these behaviors show up in rushed development, and all of them show up in the first week of real operation. Testing seriously, with real scenarios, real data and real users, is a discipline of its own, and it is exactly the stage that "90% done" projects have never been through.

Small business decisions, impact on everything

There is a third factor, and it is the least obvious one: minor business decisions can affect everything that has been built so far.

A typical example: the system was built assuming every sale goes through a manager's approval. Midway, the operation realizes that sales below a certain amount don't need approval. It sounds like a rule tweak, one sentence in the requirements. In practice, changing that flow can mean touching the data model, permissions, notifications, reports and every screen that assumed the old behavior.

Software is an organism whose parts talk to each other. When a central flow changes, the change propagates, and the rework lands precisely on what was already "done". Projects built without an architecture designed for change suffer the most from this, and that is the most common scenario among the projects that reach us for rescue.

Better to take longer and deliver than to rush and fail

None of this is an argument against speed. It is an argument against illusory speed, the kind that produces fast demos and systems that can't sustain operation.

Our position is direct: it is better to take longer and guarantee the delivery than to have something fast that doesn't work. A system that goes live two months late and runs well is an asset, as the case studies on our blog show. A system delivered "on time" that breaks in the first week of real use costs both things: the technical rework and the user's trust, which is far more expensive to win back.

That's why, when a 90% done project reaches us, the first step is not to start coding the remaining 10%. It is an honest diagnosis: a code audit, a map of what actually works, a survey of the real business flows and a replan with a truthful estimate. Sometimes the conclusion is that a good part of what exists can be reused. Sometimes, that rebuilding is cheaper than fixing. In both situations, the client leaves the conversation knowing where they stand, which is more than they had before.

Stuck with a project at the "final 10%"?

If you have a system that is almost ready but never gets ready, Espresso Labs runs this diagnosis all the time. More than 57 systems run today under our maintenance operation, many of them inherited exactly like this. Bring us the project, we'll assess what exists and hand you back a realistic plan to actually ship it.