Timeline for "Kill switch" in customer hosted environments, to protect payment?
Current License: CC BY-SA 3.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 22, 2011 at 21:54 | comment | added | Bob Murphy | +1: Great advice for all customers: late pay, stop work. About lawyers, I once did some contract programming for a lawyer-entrepreneur who stiffed me for about $14K. When I researched suing, I found the corporation I'd signed the contract with was actually just a shell with no assets. There was no way to collect on a judgment unless I "pierced the corporate veil" and got to him personally, and I figured he was too canny to put himself at that risk, so I just walked away. Moral of the story: make sure you know exactly who you're signing the contract with, and that they actually have some money. | |
| Jul 20, 2011 at 21:52 | comment | added | CaffGeek | And stop releasing the code to him until he's paid you. Host it on your own dev server, where he can view it's functionality. When he pays (or pays an agreed upon portion), then you move it to his server and collect the rest of the payment BEFORE moving any more code. You can do the work, but don't provide the product to the user until you receive payment. | |
| Jul 20, 2011 at 14:35 | comment | added | shmeeps | +1 For an incredibly ethical solution to a problem posed by an very unethical customer | |
| Jul 19, 2011 at 19:27 | comment | added | Jon Hopkins | The only thing I would add is to make sure that support isn't under a separate agreement of some sort, if it is, and if that contract is paid up then it probably can't be withdrawn. Unlikely given the background but possibly worth saying. | |
| Jul 19, 2011 at 19:14 | comment | added | Steven | +1 for 'stop all work until payments are current.' I'd recommend billing frequently (at least monthly) and ensuring customers pay reasonably on-time to avoid this sort of situation. | |
| Jul 19, 2011 at 14:36 | history | edited | Joris Timmermans | CC BY-SA 3.0 | Expanded on the "why" of stopping maintenance and support, beyond punishing the customer. |
| Jul 19, 2011 at 13:38 | vote | accept | Sam Grunion | ||
| Jul 19, 2011 at 13:38 | comment | added | Sam Grunion | It's hard to pick a best answer, but I'm going with MadKeithV, since this is how I'm going to handle the situation. | |
| Jul 19, 2011 at 8:39 | history | answered | Joris Timmermans | CC BY-SA 3.0 |