Why the Last 10% Takes Half the Time

There’s a moment in most projects where a client watches a demonstration, sees the thing they imagined working in front of them, and says some version of: “That’s it! That’s what we wanted! How long until it’s live?”

And the answer is six weeks, and the room deflates.

It’s one of the most predictable points of friction in software, and it’s almost always a communication failure rather than a project failure. The work that follows is real, necessary, and was in the software project timeline from the beginning. It’s just that from where you’re sitting, it looks like nothing is happening.

What “it works” means in a demo

A demonstration is a performance of the happy path. The right person, with the right data, doing the right thing, in the right order, on a good connection, on a machine that’s already set up.

That’s not a trick. It’s the correct way to show progress, and the happy path genuinely is the hardest creative part of the build. It just represents a narrower slice of the finished product than it appears to, because everything you’re seeing has been protected from the conditions it will actually meet.

Production is the opposite of a demo. It’s every person, with whatever data they’ve got, doing things in the wrong order, on a five-year-old phone in a lift, at the same time as four hundred other people, at two in the morning when nobody’s watching.

What’s actually happening in those six weeks

This is the list that’s invisible from outside, which is why it’s worth reading in full.

Everything other than the happy path. What the screen shows before data loads. What happens when a search finds nothing, a payment declines, a file’s too large, someone loses signal halfway through. Each of these is a decision plus an implementation, and there are dozens of them.

Real data. Demo data is polite. Real data has apostrophes in surnames, addresses that don’t fit the format, a customer record from 2014 with a field that’s null when the code assumed it never would be. Migration is routinely underestimated by everyone, including us.

Every device and browser that matters. Not a theoretical exercise. Layouts that behave beautifully at one size do surprising things at another, and someone has to check, on real hardware.

Performance under load. Fast for one person and fast for the launch-day crowd are different properties, and the second is only knowable by testing it.

Security and access. Confirming that people can only see and do what they should. This is slow, unglamorous, and precisely the work you want done unhurriedly.

Accessibility. Keyboard operation, contrast, labels, focus order. Cheap when built in, still requiring a proper pass before launch.

The plumbing that never appears in a demo

The plumbing you’ll never see. Analytics, so you can tell whether it worked. Search metadata and structured markup, so it can be found. Error tracking and monitoring, so a problem announces itself rather than waiting for a customer to report it. Backups. A deployment process. A way to roll back when something goes wrong at 6pm.

The content. Final copy, real photography, the terms and conditions somebody has to approve, the confirmation email nobody remembered to write. This one is frequently the actual bottleneck, and it usually sits on the client side.

Integrations under real conditions. The connection to your CRM works in testing. Now it needs to work when the CRM is slow, when it’s mid-upgrade, when it returns something unexpected.

Handover. Training the people who’ll run it. Writing down how it works. Making sure the business isn’t dependent on a phone call to us for routine things.

The oldest rule in software

Tom Cargill at Bell Labs put it best, decades ago: the first 90 per cent of the code accounts for the first 90 per cent of the development time, and the remaining 10 per cent of the code accounts for the other 90 per cent of the development time.

It’s a joke that has survived forty years because it keeps being true. The observation underneath it is that visible progress and remaining effort aren’t proportional. The features you can see are a poor guide to how much work is left, and human intuition insists otherwise every single time.

Was this in the software project timeline all along?

Yes, and this is the part worth internalising, because it changes how the conversation feels.

The six weeks weren’t added when you asked. They were always in the number. What went wrong is that the plan was communicated as a list of features, features got built in a visible order, and the completion you perceived ran ahead of the completion that existed. A schedule shown as “features, then hardening, then launch readiness” produces a very different experience from the same schedule shown as a feature list, even when the dates are identical.

We can do better at that, and increasingly we structure it so the unglamorous phase is named and visible from the start rather than appearing as an anticlimax.

How to make it genuinely shorter

Four things, and they all happen early.

Decide the edge cases up front. What should a customer see when there are no results, when payment fails, when they’re locked out? These are business decisions dressed as technical ones. Made early, they’re cheap. Made in the final fortnight, each one is a small negotiation on a critical path.

Get the real content in early. Not final-approved, just real. Real copy and real images surface layout and length problems while they’re still cheap, and they remove the most common last-minute blocker.

Test with real data as soon as possible. A migration attempted in week three tells you what you’re dealing with. A migration attempted in the final week tells you the same thing, far too late.

Stop adding things. A small feature added late doesn’t just cost its own build time. It costs a fresh pass through every one of the checks above. This is the single largest cause of a final stage that keeps extending, and it’s almost entirely within your control.

The uncomfortable truth

The last stretch is where a project becomes something you can put in front of customers without wincing. Compressing it doesn’t remove the work, it relocates it — into your launch week, your support inbox, and the fortnight afterwards when the team is fixing in production, expensively and in public, what could have been fixed quietly beforehand.

It looks finished. That’s the point. Making something look finished from the outside while it genuinely isn’t is what the demo does well, and the six weeks after it are what make the impression true.

Simon Paul is a Business Solutions and Technology Specialist at Code Brewery who’s spent 25+ years turning business ideas into software that actually earns its keep. He’s learned to say “this will look finished about six weeks before it is” at the start of a project rather than the end. Reach out to Simon to talk through what your launch really involves.