My second job is web design/graphic design work.

I am in a situation where a client hasn't paid a final payment on a web site. Due to this experience, I have revised my contract so that a site won't go live until final payment is paid. The old contract was a 33% down, 33% on design approval, remainder due at the end of job approach.

A contract/TOS was signed by them with a payment clause stating:

The Developer reserves the right to remove all web content from the Internet if payment is not made within thirty (30) days after delivery of our completion notification.

As the 30 days approached they were sent several emails reminding them of the clause, which they acknowledged receiving. I have saved every email correspondence with the client during the job. 30 days has passed and I am now looking at disabling the site today as a final step (before legal action).

So to the people with any experience with this, is my my 'butt covered'? In 6 years, this is the first time I have ever had to actually act on that non-payment clause. it's the last thing I really want to do, but the situation is getting ridiculous

Also, I don't know what legal issues there are with me going on the hosting to disable the site. I have full access to the hosting, and there is an authorization clause in the contract stating that.

toughie.

Half my clients pay within the 30, the other within the 30-60. I generally give leeway of a couple weeks when it's a long standing client.

Disabling is a fairly drastic measure, but I've done it. And I'm about to do it next week too. Though drastic, you may need to stand up to them, and pull it. You have a contract after all that states what each milestone is,

Pulling your work is pretty serious business. I've been woking in the industry for 12 years and I've only done it once. I certainly wouldn't do it at day 31, or even day 60. It really should only be used as a last resort.

Have you called them? Email is a **** form of communication for these types of things. It's nice to have a paper trail but sometimes a quick chat can work wonders.

I work on a 40/30/30 contract - but nothing gets delivered before the final payment is received. I have been in the business for 25 years and too many times have I delivered something whether printed brochures or a website only to be ignored when it comes to collecting the final tab on what's owed.

With a printed piece my expenses are covered with the 40/30 (initial deposit and 2nd instalment) my profit lies in the final 30 so if they bail at least I'm not out any money but I don't deliver the final piece until a cheque is ready for me as well. Of course there are a few clients this won't work with, e.g.: small government, townships and regional government office plus some of the large engineering firms too, but I know them and I'll eventually get paid although they are sllllloooooooowwwww to do so (but I also "adjust" my fees accordingly)

As for websites - nothing goes live and all access to the backend is revoked until the final invoice is paid. Once the site is live, where's the incentive to pay? For the few non-paying clients I did have in the past it was simple, I sent them a registered letter stating that I would invoke my rights to my unpaid property if my invoice was not paid by a certain date. (basically I am going to repossess it). If they didn't pay or make firm arrangements to pay I had no problem cutting them off. The only time I did cut a client off from his website (and emails because I redirected the DNS), I got an immediate response and payment. This was a drastic way to go but I was tired of empty promises and them ignoring me for payment for my services.

I did learn though is although I do give my client access to the backend so they can make changes and updates and basically have compete control over their website and files - never even give this out until your invoices are paid.

If the site has gone live on their domain and you do not host the site, then the threat to pull it is hollow -- they just have to change passwords so you can't access it to delete, or they can copy the work by FTP and put it back up on this or another server.

...A contract/TOS was signed by them with a payment clause stating:

The Developer reserves the right to remove all web content from the Internet if payment is not made within thirty (30) days after delivery of our completion notification.



...So to the people with any experience with this, is my my 'butt covered'? In 6 years, this is the first time I have ever had to actually act on that non-payment clause. it's the last thing I really want to do, but the situation is getting ridiculous

Also, I don't know what legal issues there are with me going on the hosting to disable the site. I have full access to the hosting, and there is an authorization clause in the contract stating that.

First, DO call them to try and set up a payment arrangement -- like johnnyspade says: "sometimes a quick chat can work wonders".

However, tread lightly on the subject of pulling the plug (as in don't tip your hand too early), or they may just decide to still not pay you AND lock you out by changing the account management and FTP passwords (if they have them).

You have to figure out if their intent is that they are going to pay you at all or not before deciding to kill the site -- in effect, deciding that they are deadbeat clients -- as such a gesture would pretty well nix any future work (updates/tweaks/additions) with them -- that's a shame if they just happened to be slow or late getting that last payment out to you.

Your butt IS covered if you DO decide to kill the website content after talking with them:

1 - You have a specific contractual clause to that effect.
2 - The work belongs to you until it is paid for.


As an aside, have you considered implementing a "kill switch" on your projects? It's as easy as remote-linking the CSS/Javascript in the website code to a remote server that YOU control. This gives you a LOT of leverage for very little extra coding work:

- Once you are paid, you clean up a few lines of code to re-link the files locally on the client's site server.
OR
- When the client decides to screw you over, you just move/rename/remove the remote-linked files on YOUR server and the deadbeat's site turns instantly into an ugly/non-working mess. Chances are your phone will ring pretty quickly following this.

The use of a "kill switch" is a great tool to cover yourself in cases where deadbeats refuse to pay you AND lock you out -- and also gives you more leverage to negotiate payment from a**hole clients who feel they screwed you good by getting the work for less than agreed to or even for free.

You may still NOT get paid in the end, but at least the a**hole clients won't walk away laughing WITH your finished work.

***BTW, I HAVE used this method on some jobs where I felt that payment finalization might be at risk -- and actually killed one using this method. There was a lot of cussing and gritting of teeth, but a final payment WAS made.

This method will probably get flakked here for some sort of lip-service to "ethics" (heard it before). IMO, there is nothing illegal or unethical about this extra layer of protection for designers. I personally see no wrong in implementing a method which is totally harmless and transparent for an honest client -- and which may prove valuable as a tool for dealing with a**holes.

- Daniel

toughie.

Half my clients pay within the 30, the other within the 30-60. I generally give leeway of a couple weeks when it's a long standing client.

Disabling is a fairly drastic measure, but I've done it. And I'm about to do it next week too. Though drastic, you may need to stand up to them, and pull it. You have a contract after all that states what each milestone is,

Thanks for the replies guys.

In regard to leeway, the client reads the contract before signing. If they have a good reason to amend payment terms, it can be done before the contract is signed.

However, tread lightly on the subject of pulling the plug (as in don't tip your hand too early), or they may just decide to still not pay you AND lock you out by changing the account management and FTP passwords (if they have them).

The site is setup in Wordpress (a lot of sites I work on are), so my initial plan would be just to disable their user account (editor account) and put the site in maintenance mode. I could do this even if the FTP info was changed. In this case, I don't think the client even has the know how to change the FTP info though. But a good point for future reference.

I don't question the ethics of a "Kill Switch", because the clients aren't really being ethical not paying. But what about the legalities of it? EG if it's not contained in the contract etc,?

In response to other posts about controlling the backend. A lot of the work I do is in Wordpress. Am I better to just setup the whole site proof on a remote server in that case? Then back it up and move it to the actual host when final payment has been made? I assume to move the style sheet, I would need to change code in several parts of the themes. I don't know which approach is easier/quicker?

Thanks for the info so far guys.

...I don't question the ethics of a "Kill Switch", because the clients aren't really being ethical not paying. But what about the legalities of it? EG if it's not contained in the contract etc,?...


Legalities? You have a contract clause to the effect of pulling the whole site:

The Developer reserves the right to remove all web content from the Internet if payment is not made within thirty (30) days after delivery of our completion notification.

Text passage made bold in the above by me. Notice that it says "from the Internet" and NOT just from the client's server. If the client deceives you and then deprives you of your rights as per this clause, then at least you can kill one or two files on YOUR OWN server.

In effect, we MAY call it a "Kill Switch", but all it is really is a remote link. Remote links are used all the time for content/code -- linking to google for code comes to mind, for example:

Google Libraries API (http://code.google.com/apis/libraries/devguide.html) links to the jQuery JavaScript Library v1.7.1 remotely.

"Dead Links" happen all the time on the web -- too bad if it just happens to be the case for your recalcitrant client... :-( :D

- Daniel