anchordesk - 4:34 pm on Feb 7, 2004 (gmt 0)

This might be one of those times when your payment is in the form of a lesson. It sounds like you know how to cover your bases, but just failed to do so.

I learned some valuable advice over 30 years ago from a brick mason I worked for during summers as a teen-ager. He "built in" the ability to help receive final payment into his fireplace chimney jobs. Right about the middle of the chimney stack, he'd lay in a flat piece of glass which blocked off the flue. Upon completion of the job, the homeowner could look up and down through the chimney and see a clear flue not knowing the glass was there. When the homeowner paid the brick mason, he'd get up on the roof and slide a long stick down the flue to breakout all the glass. The homeowner that would be late or "forgetful" of paying the final payment would eventually call my mason friend complaining that the fireplace does not work. He'd tell them that after final payment, he'd fix it the same day. Once paid, he'd simply broke out the glass.

Long story short, I've learned to code according to that same principle on jobs I don't have an established relationship with a client. Examples can include building the mysgl database on your server ... once paid, duplicate it on the clients server. Just make his site fully functional, yet you maintain some vital part.

A local burearcratic school district, always crying their money woes, had me make up a site once where I was concerned about payment. So I off loaded all the web email functions (web page) which allowed the community/parents/students to email teachers onto one of my domains. The entire school site ran good, looked good, they were happy with it ... but no final payment. Finally, since I still controlled the web emailing feature, I'd do a bit of automated dialoguing with anyone trying to email a school staff person. Payment came pretty quick after that. Then I simply uploaded the web email feature to their server and tied it in.

-anchordesk