I recently had a negative experience, where client bailed from the bill, but my middle-man already uploaded our software and design to the clients server. Client turned out be a known criminal, and of course he changed all possible passwords of the server.

However, I can still access the admin-panel of the CMS. Sadly it turns out, that my software is very secure.. Tried to SQL-injection, fake the image-upload etc etc. However, I cannot hack my own software.. Anyways, I preparing to sue this person, so that is not the problem.. I'm just thinking now, that maybe there should be some backend selfdestruct-method. So, if similar case occur, I have the option to kill the software.

My own idea is to hide some function in the core files. Encode it with base64, so it wouldn't be obvious. So something like this:

eval(base64_decode('ZWNobyAnSGVsbG8gd29ybGQhJzs=')); // echo 'Hello world!';

And basically make a small script, that takes all the software's files, chmod's them to be sure and then deletes them.
My newer versions of the CMS, all have filemanagers that I could use for easier hacking. But what if the access to the admin-panel is limited.

To be very clear, this is meant only for the development-stage software's, in my personal server or the clients server (last part being the ethically questionable.) So if my client should steal my software.. This wont be included inside a commercial-software.
And to be even more clear, we are talking about those rare freelance jobs. I think its fairly logical, that contract-work doesn't need such methods. So we are talking about those jumprisk-clients, only in development mode -- when the project is ready, then obviously this would be a very very unethical backdoor to have inside your software.

  1. Ethically is this a good idea? (Keeping in mind, that obviously I will remove it, when project has been 100% and everything is paid for)
  2. Have you guys ever had to hack your own software, because of similar issues with the client(s)?
  3. Any recommendations on this idea, code and method wise?
  4. What may be the possible drawbacks or repercussions of selfdestruct-scripts?

My conclusion on this

Is a little bit sad, that all answers were targeted on the contracted cases. It was my fault really, that I didn't make it more clear in my question.. just thought, that it is fairly clear, that there is no point in the kill-switch.. when you are protected by the contract.
However, if you are doing a contract work.. then this should be stated in the contract -- this makes it legal, even inside the clients own server. However, having kill-switches inside my own personal server is really nobodies business (this is what I really wanted to know.)

I decided to make the kill-switch script for my CMS. Mainly, because it seems an interesting challenge. But also, that I could use this for my non-contracted works where the client is a friend of a friend of a friend.. I probably wont use this on the clients server, but..for the cases, where the client or some middlemen have access to my server .. And my software gets stolen, or "moved without my knowledge", then I don't get paid and they cut the access to the software.

I have read trough alot of topics here, where they recommend to send a warning and then take down the page. Well, I saw a problem in it, as when Im dealing with a person.. who will just copy it to somewhere else (maybe re-brand it and sell it) and tells me, that it has been taken down. And also, I wouldn't "turn the site off", but delete it. Though, I guess its still illegal to access my clients server and to delete it. Or at-least, access it trough backend and not from the FTP. For this I thank all of you, who answered.

  • 26
    Your efforts would be better spent doing due diligence on your clients! Commented Sep 19, 2011 at 17:45
  • 14
    Leaving not just a known but deliberate security vulnerability in your code is not only unprofessional but must leave you open to legal danger.
    – Kevin D
    Commented Sep 19, 2011 at 18:00
  • 2
    back doors and bombs are presumably not part of the product specification; depending on the liability and contract laws in your country/state, this may constitute a breach of contract Commented Sep 19, 2011 at 18:21
  • 12
    I see this and immediately think, Maybe I Needing Later. Commented Sep 19, 2011 at 18:57
  • 3
    @KalleH.Väravas Freeland work != work without a contract. It means "somebody who is self-employed and is not committed to a particular employer long term". Doing work without a contract is almost always seen as a very bad idea, for the exact reason you're asking this question (client runs off without paying for the work)
    – thedaian
    Commented Sep 20, 2011 at 0:59

13 Answers 13


I'm not a lawyer. It sounds like you already have one for the purposes of suing your client; while you have him or her on retainer I would recommend getting their advice on this.

There are some other questions on this site that deal with "kill switches" and other ways to disable software for which the developer has not received compensation. It is usually considered a bad idea to simply build one in to "turnkey" software (where you will develop it and then transfer full rights to the client), without the contract having stipulated this possibility.

First off, if your contract does not specifically state that you can disable the software for non-payment, or that the client does not have any rights to the software until payment is received in full, then you cannot flip any "kill switch" without being in breach of contract. Absent any words to the contrary, "possession is nine-tenths of the law", so it's his software once he is given possession, and to destroy it would be akin to dynamiting a new office building you'd built for him if he didn't pay for it.

The second point follows; any contract you offer to any client should have a clause to the effect of: "Intellectual property transfers on satisfaction of contract". That means that even if you have given him a copy of the software to use, until he's paid you in full, he doesn't own it. This WOULD give you the right to disable his or any copy of the software for any reason until full payment has been received, because it's still yours and you can do as you please. Now, he's breached the contract, and you haven't, so the case is MUCH easier for your lawyer to present, and meanwhile your client doesn't get any benefit from his ill-gotten goods.

The analogy to a building contractor holds: once a building under construction is able to be secured against unlawful entry, it is, and the contractor will generally keep all copies of all keys to the premises until the work is complete and signed off on, and payment received in full. Even after the keys are handed over, if payment falls through he can attach a lien on the property and in the extreme have it repossessed. The same holds true here; you may give the client a key to get into the software, but you hold the "master" key, and he doesn't get administrative access until you're paid in full. If he can get in now, and doesn't pay you, you can just "change the locks" and lock him out of the software.

However, you have given your client the "master" key to the software, and he's gone and changed all the locks so now YOU can't get in. That's not the way it should work. You can still claim damages, but in the meantime your crooked client can use the software, copy it elsewhere (that's a big thing that can't happen to a contractor; if he takes his building back he doesn't have to worry that you've made an exact free copy on another lot), etc etc. Basically, your only remedy is to enforce payment in full, because you cannot guarantee that you have reclaimed all copies of the software. You probably wouldn't be happy getting your software back even if you could guarantee he had no further copies; it's likely custom work you can't just turn around and sell to someone else.

Understand that regardless of your rights to the software, his data belongs to him. You cannot touch it. You can stop his access to the software that you built, but if you destroy his data, that's like burning his possessions after repoing the building you built him that he didn't pay for. You have no right whatsoever to that data, and must either leave it in place on his computer intact, or if the data cannot be accessed in a reasonable manner without your software, you must remove it from the entanglement with your software and give it to him in a useable format (such as a human-consumable database, or printed or electronic copies).

  • 3
    Impressive answer! Thank you. I agree with you 100%, except that this question was directed to freelance works in mind, sorry I probably didn't make it clear in the question. I would never use such methods with contract-work, its just common sense and also the question would be why.. since I'm legally covered anyways. However, I'm talking about when you have an oral-contract with a guy.. who wants a car.. and you build it for him. Then he wants to see it, while you are making it.. and drives away. So, in development mode.. wouldn't it be easier to have a kill-switch.. that cuts the ignition?! Commented Sep 19, 2011 at 18:15
  • 11
    This is why you NEVER do development work for someone who isn't employing you, involving any significant time or resources, without a written contract. It's still "freelance" work, since you're representing yourself as an independent contractor, but the contract allows both you and your client to cover their behinds. It states what both sides will provide for the other (not just product and money, but resources like office space and computers), and what will happen should any of that not occur as agreed.
    – KeithS
    Commented Sep 19, 2011 at 18:27
  • Agreed, I got my lesson. Well, in theory it is correct, but it was one of those rare combinations of different variables. Friend of a friend, who wanted it cheap (1000€), my personal CMS with custom made design. I think its more clear, how the programmers community feels about this. Thank you for your answer, it still was focused more on the contracted-cases, but left the imagination for the non-contracted jobs. Commented Sep 19, 2011 at 18:34
  • Fabulous answer.
    – Teekin
    Commented Sep 26, 2011 at 17:24

In concept you are right. Your execution is all wrong.

You need to provide him trial licences that expires. Upon full payment give him the Final "forever" licence. All upfront and honest.

  • much better idea. Commented Sep 19, 2011 at 22:52
  • Indeed, first answer that doesn't argue about "why you iz not contract" or "using unlink() is ILLEGAL". I actually really like your idea, I can cook something up in CRON. Commented Sep 20, 2011 at 2:40
  • @Kalle: Nobody has said "using unlink is illegal." What people have been trying to get across is that the US, at least, has very broad laws on "unauthorized use of computer systems"; by the letter of the law, it's a crime for most of us to post answers here using work computers. Unless you have a contract granting you the right to do so, remotely disabling software running on a computer you don't own would almost certainly run afoul of this law. Whether the software you disable was stolen or not isn't likely to be relevant when the charge is unauthorized use of the system it's running on. Commented Sep 20, 2011 at 10:58
  • @Dave. I do get your point, but if you think about it. If there is no contract, so the terms and what not are not set. Then, the program is hole as it is. So, if the kill-switch was inside the code when the software got moved/stolen/delivered.. then using that kill-switch (basically unlik() function), is part of the softwares purpose.. I have talked with my lawyer, and he did point out, that hacking the software would be illegal (using filemanager to upload unlinking-script for example.) But if the kill-switch is included inside the code, as part of software, then its perfectly legal. Commented Sep 21, 2011 at 16:47

No. If your clients found out you would be lynched. It's not at all secure. Someone, some how will find out how to trigger it and then suddenly you have the task of contacting all your clients to tell them about it and why they have to do an emergency patch.

If you do hack it you are also opening yourself up to criminal proceedings. I assume you have proof you still own the site? That you have the right to access it? The cost to his business could be "astronomical"

There are acceptable alternatives. Put a watermark on the site, so every page displays a message. On payment you can remove the watermark.

  • I see. I get your point. For the record, the kill-switch was going to be included on noncommercial software, and mostly only inside my own server or at least in the development-mode only. Some clients demand, that the development would be done inside their own servers and that leaves me in a very very vulnerable situation. I currently have all files credited, designs are watermarked, my name is EVERYWHERE -- I feel pretty confident, that I will win the lawsuit.. I think having kill-switches in my own server would be still a good idea, in case someone steals them. Commented Sep 19, 2011 at 17:44

This seems like a phenomenally bad idea that could potentially land you in jail.

  1. It's unethical. Bad behavior of your client doesn't make it right for you to hack their system.
  2. It's illegal. This has happened before, with bad outcomes for the offending parties.
  3. It's pointless. What would you possibly do with this backdoor that wouldn't get you in trouble? Would you blackmail the client?
  4. It's dumb. Even if you could do this without getting caught, the potential risks far outweigh any possible gain.
  • 1
    I'm sorry, but your answer is lacking the WHY-part. Why is it a bad idea and based on what I could go to jail? Can you explain a little further? Commented Sep 19, 2011 at 17:39
  • 3
    As much as I agree with the sentiment, @Kalle is right. Please incldue a reason. -1 Commented Sep 19, 2011 at 17:47
  • 3
    Are you saying that a kill-switch is illegal? If the contract stipulates that the service will be suspended due to specified circumstances, it may not be illegal. Commented Sep 19, 2011 at 17:47
  • It depends on the legal standards of where you do business, but in general legal systems will severely punish efforts to take matters into your own hands. They really want you to go through the court system. In some jurisdictions simply accessing a computer system without permission is a felony punishable by prison time. You may argue that it's your software, but the courts will say that's for them to decide, not you. Commented Sep 19, 2011 at 17:51
  • The kill-switch method came in freelance work in mind. Sorry, I forgot to mention that in my question. I would never use such methods on a contract-work. The legal matters over here (Estonia) are in baby-steps when it comes to copyright laws. We have similar, but not the same copyrights laws like Sweden and Finland. Personally I have never had any issues with clients before.. some delay the payments etc.. but an actual thug, who steals your software -- that's new in my book. Commented Sep 19, 2011 at 17:59

Please don't ask programmers, ask a lawyer. I would imagine at the least you would want to include a clause in your contract saying you have a right to do what your question contemplates doing. (Doesn't the "irreparable harm" clause of some contracts let you get a court order to shut down the software immediately until the court has a chance to sort it out?) I think a court order would be lot safer for you than a code bomb (which could be considered criminal, if a court found you didn't own the software it could be destruction of property, in the U.S. it might possibly fall under the breaking digital encryption sections of the Digital Millennium Act, etc. I could imagine winning damages in civil court and still being convicted in criminal court).

The rules will vary depending on where you and your client live and operate, so I really think you would want a lawyer.

  • Well, the kill-switch was mostly targeted to freelance work. With a contract its much more easier. Currently the case is basically like this: My software, without my knowledge was moved out from my server and that's it. Then again, its very clear case of stealing -- so in legal wise I'm not worried. So the kill-switch would mostly be in my own server, when my software would get stolen. Though, I'm starting to feel that its still a bad idea. Thanks for your answer, I'm meeting with my lawyer in few days. Commented Sep 19, 2011 at 17:53

Ethically is this a good idea?

Absolutely not. Not only does it make you look unprofessional to honest, upstanding clients, but I feel that it's also detrimental to the profession as a whole. Software engineers do have a responsibilities to their client or employer, including delivering software that is of the highest quality. Should there be a dispute over payment or contracts, there are appropriate channels. Reducing the quality of your software is not an appropriate channel.

Have you guys ever had to hack your own software, because of similar issues with the client(s)?

Never, although I have never done contract or freelance work. I've always been an employee of a larger organization (which, in some cases, was working under a contract). To me, the thought is unthinkable. I would rather deliver software that I'm proud to have my name attributed to and get cheated by a small percentage of customers than reduce the quality of my software as well as my ethical responsibilities to the users of the system.

Any recommendations on this idea, code and method wise?

Don't do it.

What may be the possible drawbacks or repercussions of selfdestruct-scripts?

Besides the obvious ethical issues, I'd be worried about legal problems. I'm not sure if sabotaging your own work is legal, and even if it is, using such an exploit might not be.

  • Thank you for your answer. I edited my question to be absolutely clear, that this would be basically 100% hidden from the client.. As it will be mostly inside my own server and only in development mode. So when someone steals my software, I could kill it. Though, its starting to be more clear, that I should use the law and not the "force". Commented Sep 19, 2011 at 17:55
  • 2
    @KalleH.Väravas It doesn't matter where it is, but the fact that you wrote it to begin with. One could even make the argument that putting it in a development environment and not the production environment is even worse, as the two environments are no longer identical and it becomes just another variable to address during development and deployment.
    – Thomas Owens
    Commented Sep 19, 2011 at 18:10

Just implement a licensing module with time limited licenses that will disable the software on expiry. This is a well known practice in software industry and your clients should not object to it, as you will remove the limitation afterwards.

This might also come in handy, when you want to limit features and offer different versions of your product.

Kill switches just have way too many risks and are not worth it.


A secret self-destruct feature is a horrendous idea. Yes, you'll be clever and may have the opportunity to stick it to an awful client in the future, but its way more trouble than its worth.

  1. You still won't get paid for work you've done. Yes the other person won't use your code; but you'll still suffer lack of payment. You think some criminal will decide to pay the person who's already brought down their site once remotely? They'll find some new chump to make their site for free.

  2. Utilizing the self-destruct sequence, makes you liable for your own legal problems. Depending on jurisdictions, you could easily be seen as hacking/destroying their data (when they were about to pay and had plenty of extenuating circumstances for why they didn't pay earlier). Even if you aren't convicted/successfully sued, you still may mount hefty legal fees and have much more trouble than its worth.

  3. What if some good paying client browses your code later (or has a CS friend who just browsed it to do a minor tweak), sees the function with weird base64 part, is like what's this, tries executing it, and accidentally deletes the web app (and does it while you're on vacation so it takes a while to fix)? Or posts a bunch of public reviews about you everywhere stating you are unethical and leave backdoors in your work? Sure you may remove it from the finished product after they pay, but with VCS they may browse older source or not want you on their server after they paid (and that would be an awkward conversation; yes I need an account again, cause I haven't removed the secret self-destruct backdoor).

  4. What if the criminal backups their data? You delete their webserver with a secret backdoor, the site is offline for a day or two while they (or a friend) finds the offending function backdoor function and its back online.

In the future, get people to sign a simple contract, pay you in stages, and don't let code leave the development server and computer that only you control until you've been paid. (If they need it to be live before all the work is finished; make sure they've at roughly paid for the fraction of code that's becoming live). If they want to see the work as its under development, have them give you a few IP addresses which you'll open your firewall for your develolopment server (and maybe with a clever CNAME to the effect of unpaid_work_in_development.example.com). Give no guarantees of uptime of your dev server, and if you are getting way more traffic than you should be (e.g., you find they are redirect lots of people to your site) just close off the firewall until they pay. If they need to contribute content to your webserver, make them either email you with the content suggestions, or create an dropbox shared folder for them that only has permissions to write to the small subset of files (under VCS control outside of dropbox) that they can meaningfully contribute to (e.g., html templates).

  • Stick it to an awful client in the future? That sounds something what I didn't ask about or even mention. And if I don't get paid, yet he will lose the software, then how is your 1st point valid? Also there were two points in my question, is it ethical/legal to have the kill-switch inside my own server and/or in the clients server. You didn't mention which one you meant. Fairly certain, that I can have kill-switches in my own server.. So when somebody copies it, I can remotely delete it. And I think good clients are irrelevant, as the kill-switch is not included in the software. Its 1 line. Commented Sep 20, 2011 at 2:38

You've asked the wrong question. The thing to work on and improve is not to add some sort of remote kill switch (adding a vulnerability that you or someone else can use), but to fix your real problem, which was a poor way of arranging for payment and delivery. Sounds like you needed a better escrow system (or whatever such a concept is called where you live).

Don't waste your time on a kill-switch, figure out where you screwed up in the business deal part of it.

  • -1 Sorry, but your answer is off-topic. Good advice, little bit offensive but still. I don't recommend to make judgments as you don't know the full story nor do you know, how I usually make business. Commented Sep 20, 2011 at 2:32

I think I would devise some kind of licensing mechanism. This could be based on any number of commercial or home brewed ideas and could cause the software to stop working after the license has expired. At the point the system is accepted by the client and they have paid you can provide a full license that does not expire.

This approach also needs approval from a lawyer in your territory but has the advantage that you do not need to remote disable the software and you can stipulate that this is part of the system before hand. However it seems very sad to me that you are dealing with people who refuse to pay in the first place.

  • Im starting to actually love the trial-software idea. However, the second part is iffy. Basically, if the trial-licensing or even kill-switch would be a part of the software, then its perfectly legal. Depending on contracted or non-contracted work, it should be stated in the contract. Commented Sep 21, 2011 at 16:55

Isn’t this called DRM? As long as you remove the “bomb” upon receiving payment I see no legal problem with it. Just make sure you have a patch readily available to cover your ass and show that you didn’t have malicious intent.

It reminds me of the ‘poison pill’ provision in some companies’ articles of incorporation which are activated in the event of a hostile takeover.

To wit, the mentality expressed by some of the other posters here reminds me of why some programmers get stepped on all the time. If more people put such bombs in their code I think programmers might get paid more promptly... I would have absolutely no problem if this were the norm. People love to steal other people’s hard work. Period. And if Apple, et al. can DRM the hell out of their stuff, then I think freelance programmers can too...

  • I love your answer, it addresses my point alot better then other answers. I checked with my lawyer and he said, that afterwards going inside the admin panel and uploading a unlinking script via filemanager, is consider hacking -- illegal. However, if there is a actual function built-in the software.. then its part of the software and has its own purpose. This obviously should be covered in the contract, though this question is about non-contract works. Thank you for your answer :) Commented Sep 21, 2011 at 16:52

On a practical note, surely the client would check their logs, find the kill request, restore the code from a backup, remove the kill switch and re-deploy.

  • True, however this depends on the client, software, server. In my case, the client barely could change the ftp access. But checking the logs is impossible. Also, that server doesn't support any such logging..neither does my humble CMS.. Commented Sep 21, 2011 at 16:57

The details of your question make it clear that this would be an absolutely horrible idea. The first client to discover such a kill switch (possibly after you use it and they recover from a backup) would publish the kill switch and the fact that you had included it in code you delivered to them. Your reputation would then be completely destroyed.

And before you say "well, they'd be a deadbeat, how will they destroy my reputation?" Consider a scenario like this: The customer is in good standing, but one of their employees takes a copy of the code. They fire that employee, he looks at the code, figures out the kill switch, and uses it. Guess who gets the blame? (Hint: It's you.)

  • I disagree. It is actually a very good idea. If you would read the details carefully, then you would understand that i'm talking about non-contract jobs.. where in my examples case, the client is questionable. His reputation as a known thug vs. my attempt to protect myself. I don't think this will affect my reputation negatively. Your scenario sounds like contracted work.. in that case I have a contract, no need for the kill-switch. However, if there is no contract then they cannot get the copy of the code either.. Commented Sep 21, 2011 at 17:22
  • If there's no contract, then you haven't contracted for the right to activate the kill switch on their hardware, right? Bad idea. Commented Sep 21, 2011 at 17:46
  • If there is no contract, then there is no terms of what is part of the software. If the kill-switch is part of the software, then yes.. from programmers point of view: is it ethical? However, it is legal. Because the kill-switches purpose as part of the script, is to be activated remotely with the sole purpose of deleting EVERYTHING. Its legal, so why is it bad idea? Commented Sep 21, 2011 at 17:48
  • 1
    So you're saying intentionally causing someone else's computer to stop operating the way they wanted it to act without their permission (when you know that if you specifically asked them if you could do this, they would say "no") is the same legally as performing a harmless operation where you have no reason to think the owner of the system would have any objection to you doing it? I'd love to hear you pitch that to a jury. (Aiming and shooting a gun at a person is just like turning on a light switch, right?) Commented Sep 21, 2011 at 18:02
  • 1
    The answer you get is only as good as the question you ask. For example, did you ask them about the case I discussed in my answer? (A former employee figures out how to activate the kill switch.) Commented Sep 21, 2011 at 19:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.