Kill Switch for Client Projects: Built the Legal Way

You've thought about it. A few lines checking today's date, and if the invoice is unpaid, the site stops working. Tempting — and the fastest way to turn a payment dispute into a criminal one.

TL;DR: A kill switch for client projects — code that stops running when an invoice goes unpaid — is legal only when it's disclosed in the contract as a licensing condition, not hidden as a secret trigger. DevAegis builds this in as a per-project toggle: encrypted delivery, a disclosed license term, and access that restores automatically the moment the client pays.

Why developers reach for a kill switch in the first place

You deliver the build. It works. The client says so. And the second it's live on their server, every card in your hand is gone. You can't take the code back. You can't un-deploy it. The thing you spent six weeks building is now running just fine without you, invoice or no invoice.

That's not a personality problem on your end, and it's not proof the client is dishonest. It's what happens by default when working software changes hands before the money does. Once delivery and payment are separated, whoever received the delivery has no structural reason to close the loop quickly — even a client who fully intends to pay will often pay whoever's asking loudest, and that's rarely you.

So the idea of a kill switch makes sense the moment you think of it. If the code could just... stop, the way a gym membership stops when the card declines, the whole imbalance disappears. There's one line that decides whether that idea is a smart contract term or a felony, and most developers guess wrong about which side of it they're standing on.

The DIY version almost everyone has considered — and why it's not a workaround

Say you write it yourself. A conditional buried in a cron job, checking a date you control, disabling a feature or crashing the app if payment hasn't cleared by then. No line in the contract mentions it. The client has no idea it's there.

One contractor built almost exactly that, and it cost him six months of his life.

Between 2014 and May 2016, a Siemens contractor named David Tinley inserted what prosecutors called logic bombs into spreadsheet programs he'd built for the company's Monroeville, Pennsylvania plant. The code was written to malfunction after a set date. When it broke, Siemens called Tinley back in to "fix" it — work he then billed for, over and over, using a failure he'd engineered himself.

He pleaded guilty to one count of intentionally damaging a protected computer, a charge that carries up to 10 years in prison and a $250,000 fine (U.S. Attorney's Office, W.D. Pa.). He was sentenced to six months in prison, two years of supervised release, and a $7,500 fine (U.S. Attorney's Office, W.D. Pa.). Court filings put Siemens's total loss at $42,262.50 (BleepingComputer).

Tinley's motive wasn't an unpaid invoice — by most reporting, he did it to manufacture repeat work for himself, not to force a client to pay what they owed. That distinction doesn't matter to the statute. The law he was convicted under doesn't ask why you damaged a protected computer without authorization. It only asks whether you did.

There's one detail almost every homemade version of this skips, and it's the detail that decides which side of that law you land on.

Is a kill switch for client projects legal?

Yes — but only under one condition, and it's the condition the Tinley case shows what happens when it's missing: the client has to know, in advance, in writing.

Software that stops running when a license lapses is not a novel idea. It's the entire subscription software industry. Your CRM stops syncing when the card on file fails. Your design tool locks the file when the seat isn't renewed. Nobody calls that sabotage, because the terms were disclosed before anyone agreed to them — the access was always conditional, and both sides knew it going in.

A kill switch for client projects works the same way, once you set it up the same way. It's not a secret. It's a licensing term, stated plainly in the agreement you both sign: this software is licensed to run while payment is current; it stops decrypting or booting if the account falls into arrears, and resumes automatically once payment is restored. One clause. Read it, sign it, and the client has consented to exactly the mechanism you're using.

The one requirement that separates a license term from a felony

Disclosure is doing all the legal work here, but it's not the only thing that matters in practice. Three things together turn "kill switch" from a threat into a contract term:

• It's disclosed before delivery, not discovered afterward. The clause exists in the SOW or license agreement the client signed before you shipped anything.
• It's non-destructive. Nothing is deleted, corrupted, or permanently broken. Access is withheld, not damage inflicted — the difference between a paywall and a wrecking ball.
• It's reversible on the client's own action. The moment the invoice is paid, access comes back without you doing anything by hand. That's what makes it a payment mechanism instead of leverage held hostage indefinitely.

Get all three right and you've built a licensing term every SaaS company already uses. Miss the first one and you've built what a federal court calls intentional damage to a protected computer. There's no partial credit.

How DevAegis builds this in

This is the part where writing your own version, carefully, forever, stops being worth your time — which is what DevAegis exists to replace. There's also one kind of deployment where none of this works at all, and it's worth knowing about before you build around it.

You build the project normally; nothing changes about how you write code. Before delivery, you run the DevAegis CLI, which encrypts the compiled build output with AES-256-GCM — for a Next.js app, that means the built .next/server and .next/build JavaScript, turned into .dae files the client can deploy but not read. The decryption key sits with DevAegis, not inside the code you hand over.

The client deploys and runs the build on their own infrastructure, exactly as they would any other delivery. A small DevAegis runtime checks in with the DevAegis API before the app boots. Payment current, it decrypts in memory and the app starts normally — the client never sees any of this happen. Payment lapses, you mark the project unpaid from your dashboard, and the runtime stops decrypting. The build doesn't crash or corrupt anything; it simply doesn't boot, and visitors see a payment-status screen instead of the client's site. Mark it paid, and access restores itself, automatically, the next time the runtime checks in.

Two things make this different from writing your own version. First, the license term is a single clause you put in the contract you already send — DevAegis doesn't draft it for you, but it's the same one-sentence disclosure that makes the whole thing legal, and you keep full control of when it triggers. Second, nobody has to write, hide, or maintain a hand-rolled date check that a client's next developer might find, misread, and report as exactly what got Tinley convicted. You get the toggle in your dashboard instead of the risk in your codebase.

The same delivery, two ways it plays out

This is one illustrative sequence, not a specific project or client. It's the shape a fixed-price build with no deposit tends to take once the invoice goes quiet — run both ways, from delivery to the moment it resolves.

What to do next

Before your next project ships, write the one-sentence license clause into the contract, then set delivery up through DevAegis before you send the final build — not after the first payment goes quiet. If you're already chasing money on something you delivered without any of this in place, that's a different problem with a different first step.

When a kill switch isn't the right tool

It needs a network. If a client's deployment is fully air-gapped — a factory-floor system, a classified environment, anything with no outbound connection at all — the runtime can't check in with the DevAegis API, and a kill switch simply won't run there. You're back to contract terms and a deposit for that kind of client.

It can also collide with procurement rules. Some enterprise and government contracts flatly prohibit vendor-side remote disable mechanisms in delivered software, kill switch or otherwise. Read the client's own procurement terms before you build this in, not after.

And if the client is willing to fully fund an escrow account before you start, a funded escrow service solves the same problem without touching the code at all — sometimes the simpler tool is the right one.

FAQ

Isn't a kill switch just a nicer name for the same thing Tinley did? No — the mechanism can look similar, but the legal difference is disclosure and authorization. Tinley's logic bombs were hidden from Siemens and never agreed to. A kill switch written into a signed license term is something the client consented to before you delivered anything, the same way they consent to a subscription lapsing when a card declines.

Do I have to tell the client exactly how the kill switch works? You have to disclose that access is conditional on payment and that it stops and resumes automatically — that's the licensing term. You don't need to hand over the encryption details or the CLI internals, the same way a SaaS company discloses "access requires an active subscription" without publishing its billing engine's source code.

What happens if the client disputes the invoice instead of just ignoring it? A kill switch enforces payment status, not who's right in a dispute. If a client raises a genuine, good-faith dispute about scope or quality, that's a conversation and possibly a contract question, not a moment to flip the toggle — reserve it for non-payment, not disagreements about what was owed.

Can a client remove or work around the kill switch themselves? Not without the source, which they don't have — delivery is encrypted build output, not readable code, and the decryption key stays with DevAegis rather than inside the files you hand over. Domain locking on top of that stops the build from simply being moved to different infrastructure to dodge the check.

Does any of this replace having a contract? No. The license clause that makes a kill switch legal has to live somewhere, and that somewhere is your contract. DevAegis doesn't draft, review, or replace legal agreements — put the clause in plain language, and for anything unusual about your client or jurisdiction, have a lawyer look at it before you rely on it.