A project is not finished when the software works. It is finished when someone who was not involved in building it can operate it, change it and explain it to a third person.
That standard sounds like documentation, and documentation is the smallest part of it. Most of the work happens much earlier, in decisions that were either made explicitly or made by accident.
Delivery is not a phase after design
Treating delivery as the stage that follows design guarantees a particular failure: choices with delivery consequences get made before anyone responsible for delivery is in the conversation, and are then discovered as constraints rather than decisions.
Keeping the same person accountable across both is one way to avoid it. Where that is not possible, the substitute is making the delivery constraints explicit early enough that design can respond to them rather than collide with them.
What makes a handover cheap
Conventional code, consistently applied, is worth more than clever code with a good explanation. So is a project that runs the same way on a new machine as it does on the one it was written on—dependencies pinned, configuration declared, setup reduced to a short procedure that actually works.
The test is simple and worth running before the end: give the repository to someone who has not seen it and ask them to make a small change. Whatever they have to ask you is the documentation that does not yet exist.
Decisions need an owner and a record
Most of what is expensive to reconstruct later is not how something works but why it is that way. The alternative that was rejected, the constraint that forced the shape, the thing that was tried and did not hold.
Recording those is cheap at the time and nearly impossible afterwards. It does not require a formal process: a short note attached to the decision, kept where the code is, is enough to save a successor from repeating the experiment.
Finishing properly
The last ten per cent of a project is where the accountability usually thins out, and it is exactly where the handover is either created or lost. The work is unglamorous: removing what is no longer used, writing down what only one person knows, confirming the operational path.
It is also the part that determines whether the client owns what they paid for or merely possesses it. A system that only its author can maintain was not delivered; it was rented.