My advice is not to bring it up. Most of them aren't even going to consider it. They'll think that just having the code will be enough.

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.

I agree. Most clients don't worry about technical details. "People don’t want a drill,they want a hole."

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.)

Double True, most clients aren't going to think about it.

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 agree and in most cases that works. Now I have a customer who thinks there should be at least 3 developers involved in the project which is totally unrealistic because it's a relatively small project (two months for one person).

The code should be self-explanatory for a developer, if not add documentation inside the code.

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.