Remote Kill Switch - Make Sure You Get Paid | Hacker News Reader

Remote Kill Switch - Make Sure You Get Paid

billda.com

4 pointskaripatila7 comments

IANAL:

Be warned, although this may be morally justified, and very tempting, it may also be illegal. A similar situation might be that you could feel morally justified in putting a trap in your house while you are away, but it is illegal to do so.

Yeah, in most areas the law dislikes "self-help" as it is termed (http://en.wikipedia.org/wiki/Self-help_%28law%29).

There's US case law on this particular area; I vaguely remember that it's not totally opposed to the idea but in general it is.

As long as you make it explicit upfront that you're doing this (i.e. have it in your contract) then there shouldn't be any problems.

Bill here - I wrote the article linked above and designed this kill switch.

It's been helpful to me several times when I've had trouble collecting from clients, but I only use it as a last resort. There's a pretty good comment thread on the post debating the ethics of the matter.

Also Acid_bath - I recognize what you're saying about validating over HTTP. It would not be acceptable for all my clients' sites to go down if my validation server goes down. That's why my code is configured to only disable a site if it is able to explicitly retrieve a KILL signal. No response from my server is interpreted as a lack of KILL signal, thus the site stays up.

Sorry, but this reads to me like: 'If you hire me, I will backdoor my code! Do not trust me!'

Not that I'd do this, but I can at least see the appeal. Just about everyone who wasn't a "big name" that I've contracted for has dicked me in some way. Demanding more work before payment, or dropping off the face of the earth, or "suddenly realized" that 100 hours of work at $100/hr is going to be $10,000, etc.

I realize both parties are taking a risk that the other won't deliver, but once a project is done the situation is heavily in the favor of the person who hires the contractor. At that point the employer has everything they want and the contractor has nothing (or maybe some up-front cost). A method for being able to "un-deliver" or "repo" an un-paid-for product would have been useful to me many times. But un-like a car or house, I can't just take it back.

That being said I'd be paranoid that something would accidentally trigger the validation mechanism. Any time it validates over HTTP there's a chance the server won't make a connection for various reasons, and then you look like an ass.

"Not that I'd do this, but I can at least see the appeal." I think everybody does. Me too, but still this is sending out the wrong message and could fire back.

If the client is not able to provide me with a certain level of trust, I will not work for her. In case the situation is fishy... like me having this strange feeling that the client is not as trustworthy as she seems, I invoice early and often. It is way more easy to bill five times for 2k, then to ask for 10k at once.

Quoting myself from another thread: When I have a new customer, I tell her that I will send an invoice after a few (10-20) hours of work. She will learn very early what results I can produce in those few hours and whether she likes working with me. I learn very early about her the willingness to pay. I then do my invoicing based on the results of that first test.

Usually I invoice my customers once per month. Some only, if they 'used' 50+ hours. It is all about trust. One customer wants an detailed explanation for every hour in the invoice, so I invoice often. Makes it way more easy for me to get my money. Another customer is very relaxed and just pays what I tell him. I invoice him twice a year.

You are very right about being paranoid that the trigger could misbehave somehow. Code contains bugs. Less code less bugs.

Reply on news.ycombinator.com