The last sentence strikes me as sort of old school and somewhat client-hostile. Unless you're working on an embedded system that will ship physically and never be opened again, your code is going to have to change--if for no other reason than to accommodate changes in the underlying technologies. This is especially true considering the libraries and dependencies that are baked into software projects today.

If a critical security patch requires a change in the code, your client is going to have to either change it themselves or get you on the job pronto... and do you really want to set the expectation that you will be available pronto, forever?

I think the days of write the code, launch, then ride off into the sunset are over. Code should be considered temporary and perishable, and IMO consultants should acknowledge that upfront and help their clients plan for it.