Why the Last 10% of a Software Project Takes as Long as the First 90%

"It looks basically done"

Every software project reaches a moment where it looks finished. The screens are there, you can click through them, the demo goes well, and everyone in the room relaxes. Someone says the words: "it looks basically done."

Then weeks pass, and it is still not shipped.

This is not a sign that something has gone wrong. It is one of the most well-understood patterns in software, and it has a name.

The ninety-ninety rule

Back in 1985, a programmer at Bell Labs called Tom Cargill described it like this:

The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time.

It is a joke — the numbers deliberately add up to 180% — but it endures because every experienced developer recognises it as true. The visible, satisfying part of building software goes quickly. The last stretch, the part nobody sees, takes far longer than anyone expects.

The reason it keeps catching people out is that the demo and the finished product look almost identical from the outside. The difference is almost entirely underneath.

Some analogies that make it click

If you have never built software, "the last 10% is the hard part" can sound like an excuse. It is not. It is the same phenomenon you have already lived through in other parts of life.

Building a house

A timber frame goes up astonishingly fast. In a week or two you can walk through the rooms, see where the kitchen will be, look out the window openings. It looks like a house.

Then comes the plumbing, the wiring, the insulation, the plasterboard, the tiling, the fixtures, the paint — and finally the snagging list, that maddening final walk-through where you find the door that sticks, the tap that drips, the light switch wired to the wrong room. The frame took two weeks. The finishing takes months. Nobody looks at a bare frame and calls the house done, yet that is exactly what "it looks basically done" means in software.

The last leg of a road trip

You have driven eight hours and you are twenty minutes from home. Those twenty minutes feel longer than the whole rest of the trip. The scenery is boring, the excitement is gone, and every red light is agony. Finishing software has the same texture: the exciting part is over, what remains is unglamorous, and it drags precisely because you can already see the destination.

Editing an essay

Anyone who has written seriously knows the first draft is the easy bit. Getting the words down is a good day's work. Then you edit — and the final polish, cutting the flabby sentences, fixing the one paragraph that never quite worked, checking every fact — takes as long as the draft did. The draft is the demo. The edit is the last 10%.

The restaurant kitchen

A talented cook can make one perfect plate. The hard part of running a kitchen is making that same plate perfectly four hundred times on a Friday night, quickly, consistently, when three orders are wrong and the fryer breaks. Software is the same. Making a feature work once, for you, on your machine, with clean data, is the demo. Making it work every time, for everyone, under load, is the actual job.

The theme running through all of these: the visible part is the small part. Like an iceberg, most of the work sits below the waterline where the client never sees it — until it is missing.

Why this happens in software specifically

So what actually is that last 10%? It is not one big thing. It is a thousand small ones.

The happy path is the easy path

When you build a demo, you drive it down the "happy path" — the ideal sequence where the user does exactly what you expect. Real users don't. They leave fields blank, paste in a phone number with spaces, hit the back button mid-payment, upload a 40-megabyte photo, lose signal halfway through. Every one of those is a case that has to be caught, handled, and tested. The happy path is maybe 10% of the possible paths. The other 90% is where the time goes.

Real data is messy

Demos run on tidy, made-up data. Real businesses have twenty years of spreadsheets with inconsistent formatting, duplicate records, and fields people used for something other than their intended purpose. Wiring the software up to real data reliably uncovers problems that the demo never could.

You don't control the other systems

Modern software talks to other software — payment providers, email services, mapping tools, government APIs, whatever your accountant uses. Each of those integrations behaves in its own way, fails in its own way, and has to be handled defensively. You cannot see any of this from the front of the app, but it is a large share of the real work.

"Done" means more than "working"

For the demo, "done" means it works. For the finished product, "done" also means: it works on an old phone and a big monitor, it works for someone using a screen reader, it is secure against people trying to break it, it loads quickly when a thousand people use it at once, it can be deployed and updated without taking the site down, and it does something sensible when things go wrong. None of that is visible in a click-through. All of it takes time.

This is the definition-of-done gap — the quiet distance between "I can show it to you" and "I can hand it to the world." That gap is the last 10%.

What this means for planning your project

None of this is a reason to despair. It is a reason to plan honestly. A few things follow from it.

The demo is not the deadline. When you see a working prototype and it looks nearly finished, resist the instinct to move the launch date forward. What you are seeing is the frame of the house, not the house. The most expensive mistake a stakeholder can make is committing to a date based on how the demo looked.

Budget time and money for the finish. If the visible build took eight weeks, the finishing work is not a rounding error — it can be another eight. That is not padding or inefficiency; it is the actual shape of the work. A plan that allocates a token few days to "final tweaks" is a plan that will slip.

Name it up front. The single best thing you can do is talk about this before the demo, not after. When we tell a client early that the impressive-looking prototype represents the first half of the journey and the unglamorous half is still to come, nobody feels misled when it arrives. Setting the expectation is not managing disappointment — it is building trust. A client who understands the ninety-ninety rule becomes a partner in getting the last 10% right, rather than someone wondering why the "nearly finished" project is taking so long.

Value the boring part. The edge cases, the error handling, the performance work, the security, the accessibility — the stuff nobody demos — is precisely the stuff that separates software people rely on from software that embarrasses you three weeks after launch. The last 10% is not the leftover. It is where quality lives.

The bottom line

The first 90% is the fun part: fast, visible, satisfying. The last 10% is edge cases, messy data, integrations, testing, and polish — slow, invisible, and every bit as much work.

"It looks basically done" and "it's done" are two genuinely different statements, separated by real, necessary effort. Once everyone in the room understands that, the last 10% stops being a source of frustration and becomes just another planned, respected part of building something that actually works.

If you are planning a project and want a realistic picture of what it takes to get all the way to the finish line — not just the demo — we are happy to talk it through.