The real cost of software that's almost done

There's a familiar shape to software projects that go wrong. The demo looks great. The core flow works. Everyone's optimistic. And then the project spends the next six months in a state best described as 'almost done.'

The trouble is that 'almost done' isn't a percentage, it's a category. The remaining work is qualitatively different from what came before: the edge cases, the error states, the migration scripts, the observability, the thing that happens when two users click at once.

This is the work that separates a demo from a product. It rarely shows up in a sprint plan because it's hard to point at. But it's where reliability comes from, and reliability is the whole reason anyone paid for the software in the first place.

The teams that ship well don't treat this work as an afterthought. They budget for it explicitly, they surface it early, and they resist the temptation to declare victory at the demo. Done is a much higher bar than working, and the gap between them is where trust is won or lost.