How to Protect Your Code as a Freelancer (or Agency)

You've shipped the project. The client has the code, the login, the domain — everything except a reason to ever pay you again.

Maybe they go quiet on the final invoice. Maybe a different developer shows up weeks later, working from a copy of your repo. Both are the same problem: you handed over a finished, working product before you had anything guaranteeing you'd get paid for it. That's why how to protect your code as a freelancer is really two questions — protecting the invoice, and protecting the code itself.

TL;DR: Contracts and deposits protect the money side of a project; they do almost nothing for the code itself. The real answer to how to protect your code as a freelancer combines three layers — a signed license, a deposit before you start, and delivery that stays conditional afterward: encrypted code, a domain lock, and a kill switch that turns off access the moment an invoice goes unpaid, and restores automatically once it's paid.

Two ways this goes wrong, and they're not the same problem

The first way is the one everyone talks about. You deliver, you invoice, and the replies get shorter until they stop. Freelancers Union's 2022 survey of New York freelancers found that 62% had lost wages at least once to a client who simply refused to pay, and 53% of those had written off $10,000 or more. That's not a fringe outcome. It's closer to a coin flip over a career.

The second way barely gets discussed, because it's almost never discovered. A client takes the source you delivered and reuses it on a second site. Or they hand it to a cheaper developer to "finish up," and that developer just needs to read the code, not write it. You find out by accident, if you find out at all.

Both failures trace back to the same moment: the point where you handed over something that worked, unconditionally, before the money was actually in your account. Everything downstream — the silence, the reuse, the resale — is just what happens next.

There's a third pattern hiding inside the first one, and it's worse than a client going quiet on day one. It's the client who pays half.

What actually protects a freelance developer's code

Start with what's real, because most of it genuinely helps — up to a point.

A written contract states what was owed, what was delivered, and when payment was due. If a dispute ever reaches small claims or arbitration, that document is what a judge or arbitrator reads first. It does not, by itself, make anyone pay you. Enforcing it still requires a third party — a court, a platform, a collections process — to act on your behalf, and that party moves on its own schedule, not yours.

A deposit changes the economics of walking away. If a client has already paid 30–50% upfront, ghosting you costs them something. It just doesn't cost them the whole project, which is why the final invoice is the one that tends to go missing.

Escrow is a real, useful tool, and it's worth understanding exactly what it does. Upwork's Fixed-Price Payment Protection holds a client's money in a neutral account before you start work, and if the milestone was funded and your deliverable matches the brief, Upwork will step in on a dispute. That's genuine protection — conditional on one thing: the client has to fund the milestone first. A small business client paying you directly, off-platform, has no equivalent obligation, and most of them will refuse if you ask.

An IP or ownership clause in your contract says who owns the code and what happens if it's copied. It's worth having. It also assumes someone eventually finds the copying, and reads your contract, and cares that they got caught.

Every row in that table shares one blind spot, and once you see it you stop trusting any of them to work alone.

Why contracts, deposits, and escrow all have the same blind spot

Look at that table again. Every row protects something that happens before or around delivery. None of them travel with the code after it ships.

That's not a flaw in any single method — it's a shared design assumption. Every one of these tools was built to protect a transaction: the promise to pay, the promise to deliver. Once the transaction is technically complete — the code is live, the client has it — the tool's job is done, whether or not the money actually arrived.

Delivery is the one moment none of the standard advice touches, because delivery is usually irreversible. You can chase an unpaid invoice. You can't usually un-deliver a working website — unless the delivery was built to stay conditional, and there's a specific way to do exactly that.

How to protect your code as a freelancer, step by step

This is where DevAegis fits, and it's worth being precise about what it actually does, because the mechanism is simple.

Before you deliver, three things happen on your side:

1. You build normally. No change to your stack, your editor, or how you write code.
2. You run the DevAegis CLI. It encrypts your compiled build output with AES-256-GCM. For a Next.js project, your build runs through the normal next build, and the CLI then encrypts the compiled server and build files into .dae files before the app is booted. Vite, Create React App, Express/Fastify, and generic Node projects are supported the same way.
3. You deliver the whole project — every file, every folder. Nothing is hidden or held back. The client gets the complete codebase.

After it's in their hands, the code stays conditional:

1. The client deploys it on their own infrastructure. A small DevAegis runtime checks in with the DevAegis API. While the project is in good standing, it decrypts in memory and the app boots exactly like normal.
2. If the invoice goes unpaid, you flip one toggle in your dashboard. The runtime stops decrypting. The client's app stops booting. They see a payment screen where their homepage used to be.
3. You mark it paid, and access restores itself. No redeployment, no support ticket, no waiting on you to be available.

The build can also be locked to the client's domain, so a copy that ends up on a different server simply won't run there — which is what actually stops the quiet version of this problem, the reuse and resale that never shows up in a nonpayment survey because nobody ever sends an invoice for it.

One condition matters more than any technical detail: the kill switch has to be written into the agreement before you deliver, as a licensing term — "access is conditional on payment," the same clause every SaaS company on earth already operates under. You are not sneaking anything into the codebase. You're licensing software, and the license has a condition attached, disclosed upfront.

So does that mean escrow, deposits, and contracts are now pointless? No — and there's exactly one situation where escrow is still the better call.

Is escrow ever the better choice?

Yes, and it's worth saying plainly, because a guide that pretends one tool wins every case earns less trust, not more.

If a client is already willing to fund the full amount in escrow before you start — common on marketplaces, less common with direct clients — that money is locked in before you write a line of code. DevAegis doesn't do anything at that stage; it has nothing to secure yet, because there's no delivery to protect. In that specific setup, funded escrow is simpler and it needs no configuration from you.

Where escrow runs out of road is everywhere else: the direct client who won't fund a third-party account, the retainer relationship with no single "milestone" to escrow, and every case where the code itself — not just the invoice — is the thing you're worried about. DevAegis was built for exactly that gap: the leverage that exists after code ships, which escrow was never designed to reach.

There's a fair question sitting underneath all of this, and plenty of developers hesitate on it before they hesitate on anything else: does gating the code put you on the wrong side of the law?

Why the numbers don't work in your favor either

Even when a client is local and reachable, the math on enforcement is worse than most freelancers expect. In California, small claims court caps an individual's claim at $12,500, with filing fees up to $100 — manageable if your invoice is close to that ceiling, and a genuinely bad trade if you're chasing a $2,000 balance and burning a week of unbilled time to file, wait for a hearing date, and show up.

Cross-border makes it worse again. Small claims processes are built around a defendant who lives where the court sits. A client three time zones away with no local assets is, in practice, outside the reach of a process designed for local disputes. None of that changes whether the debt is real. It only changes whether pursuing it is worth what it costs you.

This is exactly why a delivery-side fix beats a recovery-side one. Recovery has to happen after the fact, through a system built for a different kind of dispute. A kill switch doesn't ask a court to do anything. It just stops asking the client's server to keep running your code.

Protecting deliverables across multiple clients

Agencies carry a version of this problem that solo freelancers don't: it's not one invoice, it's a portfolio of them, spread across clients with different payment habits and different account managers who may not even know which projects are current.

The same mechanism scales down to project level rather than up to some agency-wide switch. Each client, each build, and each payment status stay separate — one client falling behind doesn't touch another client's access. Team permissions mean a project manager can see and toggle the projects they own without touching billing for the rest of the agency, and an exportable, timestamped audit trail gives you a record of exactly when a project was delivered, when access was suspended, and when it was restored — useful internally, and useful if a client disputes the timeline later.

None of this requires the client to install anything or agree to anything beyond the license terms already in your contract. That matters for agencies dealing with procurement departments and enterprise clients who won't sign up for a new platform just to protect your invoice.

Does the kill switch expose you legally?

Not when it's handled the way it's meant to be: disclosed in the contract before delivery. What creates real legal exposure is the opposite move — reaching into a system you no longer have a contractual right to touch, after you've already granted unconditional access. That's a different act entirely, and it's not what this approach does. The access was never unconditional in the first place; the condition was in writing from day one.

What the same handoff looks like both ways

Same client, same project, same seven weeks. Change one thing: whether the build that shipped in week one will run anywhere other than where it was licensed to run.

Everything else about the client's behavior stays identical, including the part where they quietly bring someone else in.

What to do next

Pick your next project — not the one you already delivered — and add one clause to the contract before you send it: access is licensed, not granted outright, and it's conditional on payment clearing. Then encrypt that delivery with DevAegis before you ship it, so the clause has something backing it up. The user guide walks through the CLI setup, and pricing is on its own page, not buried in a sales call.

You can't fix the invoice you've already lost this way. If that's the situation you're in right now, what you can still do about a client who isn't paying covers the recovery routes that actually exist. This is about the next one.

Frequently asked questions

The questions below come up most often from freelancers and small agencies working out how to protect their code and their invoices at the same time.