On the other hand, I've seen projects get to 99% and they provide value for a few months and then because they never get to 100%, every time there's an issue no matter how small, it's very difficult to debug and the original owner has moved on to a new project or left the company so users are left holding the bag or they just end up deciding to stop using the product or build a new one.
Software is a living organism, or it is dying. Just as a practical observed matter of how it actually works out.
There are a few exceptions, but few indeed.
You can pretty much play any game pre PS3 era still enjoy it to it's fullest.
Whatever shenanigans were done late in the project, if it passed QA, that code base was effectively read only, with little concern for ongoing maintenance.
On to the next one.
Think BIOS/vacuum cleaner/shaver/toothbrush/alarm clock/dumbphone/non-smart TV/airplane kitchen equipment/medical diagnostics devices/PLC's that control most of the entire world's infrastructure and so on.
It's entirely possible and very common to have an actual "final" software release and be just fine (at least up until recently before the whole "everything needs to have internet for telemetry" hype).
Updateability is the defining advantage of software over pure hardware solutions. If you don't use the advantage then you are stuck with just all the disadvantages.
Some products with software continue to "live on" successfully and thrive, without updates. Think of a digital alarm clock who's goal was to help typical users to wake up on time most of the time. If you ship a product that does that and it isn't being updated, is the product really dying or doomed to failure?
No alarm clock will ever wake everyone up on time, but we can always strive to get closer to that goal if we chose to set that goal. An unreasonable goal could cause unnecessary bike shedding, etc.
But a simple pacemaker for the heart, the goal is closer to the idea of helping as many people as possible, rather than most. Hopefully we write good software and we go 15 years without needing an update. I think that is better than bad software that has to receive more updates. Which software is more "alive" and "thriving". Is the good software with no updates for 15 years really "dying" since it isn't "improving"? Again, thriving and improving shouldn't be conflated.
So, a product setting appropriate goals helps determine how much maintenance is actually necessary and some goals can be met without requiring any future maintenance. Other goals may benefit from frequent maintenance. Some products can thrive without improving. A product's goals determine's the importance of improvements.
The best code I've written is the code that's still running 15+ years later and no one even thinks about.
If a project is successful, it isn't 99% done; essentially it will never be done so long it is alive, supported, and/or used by anyone (I won't get into semantics here).
As others have pointed out, many of those things should be done way earlier as part of the development, AND as part of the ongoing development/maintenance after launch.
On another note I'm also skeptical that a project should ever be 100% done even if that was possible. I had the privilege of working on a project during the whole lifecycle, including when it was deprecated and eventually decommissioned. It was very pleasant to go through all of the open Jira tickets for this product and close them as Won't Fix forever. All of those features, bugfixes and enhancements were never implemented. The project launched, lived, and died without them, and it was fine.