Do you just document everything very thoroughly and convince them that's enough for an other developer to pickup?
Of course, you should document things when appropriate, and your code should be good, clean, and maintainable. It's what they're paying you for.
Add the documentation for the unusual parts in case some moron has to continue with the project six months later, and imagine that the moron is you, so be careful.
Somewhat related: "Don't Call Yourself A Programmer, And Other Career Advice" http://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pro... (I don't like the title, but I like the article.)
If you bring it up as a feature of your services that everything is well documented so another developer can pick up the project and run with it. Even bringing It up in a positive way would probably just make them worry.
I like to document anything the client will have at some point to touch. Deployment and configuration must be documented.
There are two different things to consider: - Your client beeing able to deploy or use what you give them. - Your client beeing able to modify or add features to the existing code.
Always do the first one. I always discuss this kind of things before starting a project with the client. And everything discussed is mentioned inside the contract.