In agile economics we often talk about stopping the project before it 100% complete; when you reach a point of diminishing returns; i.e. that agile fail-safe point when the cost of producing software is greater than the value of the software itself. Kind of.
So let’s try a weird-ish thought experiment. You’re in such a project and you’ve reached this point. You are about to start the dead last sprint and then it’s over. The team will be disbanded, but the software will live on.
You have just one more opportunity to work on this product, with this code base, with the people on this team. Your legacy is in this software. Every decision you made is sitting in a vast time line of deltas in your version control repository, all the way back to day 0.
What do you choose to do in this last sprint?
f3yourmind 
Making changes at this stage will be costly.To re-factor would be very risky.
I would focus on getting things right that pose low risk.
Like system documentation, having neat code, licensing information, user documentation, architectural documentation, recommendations, overview of system behavior…
Better to leave a great stage for future maintenance, over a system that does everything you envisioned, but that’s difficult to improve. Transferring that knowledge will allow future programmers to build on your vision.
Wish you made one of those delta decisions differently ? Better to say & document that now. At least your legacy will say you had the right attitude :).
Michael,
Why did you assume that your code base was in mess? What if it was really good? Then, what would you do?
🙂