What To Do When a Client Doesn't Pay (Developer Guide)

Let me tell you about a project I was genuinely proud of. The build was exactly what we agreed — fast, polished, the kind of work that gets noticed industry-wide. And after I delivered it, the client didn't pay the final balance. I made the hard call to take the production site offline, because the rights to that work had never transferred. It was uncomfortable. It was also the correct, contractually sound thing to do.

This post is the guide I wish I'd handed my younger self: what to do when a client doesn't pay, and — far more importantly — how to structure engagements so it almost never gets that far. I've been a freelance creative developer for over eleven years. Non-payment is not a reflection of your craft; it's a business risk, and business risks are managed with systems, not feelings. None of this is legal advice — for the contract itself, talk to a lawyer in your jurisdiction. This is what has worked for me.

Reality check: great work still gets stiffed

The most damaging myth in freelancing is that if your work is excellent enough, clients will always pay gladly. They won't. Non-payment happens to award-level work, to senior developers, to people with airtight portfolios. Cash-flow problems, internal politics, a change of contact, plain bad faith — none of it has anything to do with how good your shaders are.

Internalising that is the first step, because it moves the problem from "what did I do wrong?" to "what's my process for this?" The second framing is the one that gets you paid. Everything below is that process.

Prevention is 90% of getting paid

Almost every non-payment story I hear could have been prevented before a single line of code was written. Leverage is something you build into the engagement at the start — you cannot manufacture it after delivery.

A written contract, every time

No contract, no work. Even for a friend, even for a "quick" job. The contract doesn't have to be intimidating — a clear written scope of work that both parties sign is enough to change the entire dynamic. It should cover at minimum:

• Scope and deliverables — exactly what you're building, and explicitly what you're not. This is your defence against scope creep, which is its own slow form of not getting paid.
• Payment schedule — amounts, dates, and what triggers each payment (see milestones below).
• Revisions — how many rounds are included before extra work is billed.
• IP and usage rights — the clause that protects you most. More on this next.
• Kill / termination terms — what happens if either side walks away.

For the contract itself, a one-time consult with a lawyer to produce a reusable template is one of the best investments you'll make as a freelancer.

IP transfers only on full payment — in writing

This is the single most important sentence in your contract:

All intellectual property rights in the deliverables remain the property of the developer until payment is received in full. Upon full payment, ownership transfers to the client.

That clause is what turned my own bad situation from a loss into a stalemate I controlled. If the client hasn't paid, they don't own the work — which means I have every right to withhold it, and to take down a deployment I control. Make the same point explicit about the source code, the design assets, and any custom shaders or components. Until the final invoice clears, it's yours.

Deposit upfront, then milestone payments

I don't start production without a deposit, and I don't recommend you do either. A typical structure:

Phase	Trigger	% of total
Deposit	On signing, before any work	30–50%
Milestone	On approval of a major phase (e.g. design/build complete)	20–30%
Final	Before production handover / launch	balance

Two principles make this work. First, the deposit covers your downside — if the project dies early, you've been paid for the work you did. Second, the final payment lands before handover, not after. The moment you transfer files, push to the client's hosting, or point the domain, your leverage evaporates. Get paid while you still control the deploy.

This isn't aggressive; it's normal. Builders, photographers, and architects all work this way. Clients who commission good work expect it. If you want a deeper breakdown of how scope and phases map to budget, I wrote about what an animated website actually costs — staged payments fall naturally out of a well-scoped quote.

Keep the work on infrastructure you control

Until you're paid in full, host the build on your staging or your deploy — your Vercel project, your subdomain, your preview URL. Don't push to the client's production hosting or hand over the repository early. This is the practical mechanism behind the IP clause: if you control the deploy and the rights haven't transferred, withholding launch (or taking a live site down) is simply exercising your contract, not "holding the site hostage."

Be crystal clear from day one about who owns the domain and hosting accounts. A common, avoidable mess is the client owning the domain while you control the build, or vice versa. Decide it in writing up front.

Invoice like a professional

Sloppy invoicing invites slow payment. A few habits that measurably help:

• Invoice promptly — the day a milestone is hit, not "end of month."
• Clear terms — state net 7 or net 14 explicitly, with the due date as an actual date.
• Late-payment terms in the contract — a stated late fee (e.g. a percentage per month overdue) gives a polite reminder real teeth.
• One unambiguous total, the payment methods you accept, and your business details.

Prompt, professional invoices signal that you run a tight operation — and tight operations get paid first.

When it happens anyway: a calm escalation ladder

Even with all of the above, an invoice will eventually go quiet. Work the ladder in order, staying professional at every rung. Bitterness costs you leverage; calm keeps it.

1. Assume the best, send a friendly nudge. People miss emails. A short "just checking this didn't slip through" clears most late payments without drama.
2. Formal reminder. Reference the invoice number, the due date, and the agreed terms. Factual, not emotional.
3. Exercise the leverage you legitimately have. This is where the setup pays off. If IP hasn't transferred and you control the deploy, you are within your rights to withhold handover — or to take down a deployment you own. State plainly that the work transfers on payment, per the contract.
4. Final written notice. A clear deadline and the next step if it passes. Keep it dignified; you may need to show this to a third party later.
5. Escalate. Depending on the amount and jurisdiction: a small-claims filing, a solicitor's demand letter, or a collections service. Often a lawyer's letterhead alone resolves it.
6. Know when to cut losses. Sometimes the time and stress of chasing exceeds the balance. Walking away — having protected your work and kept your dignity — is a legitimate, sometimes smart, business decision.

Throughout, document everything. Keep the signed contract, every invoice, and a written trail of communication. If it ever escalates, that paper trail is your case.

The integrity angle — why this matters beyond you

Taking a site offline is never satisfying, even when it's right. But protecting your work protects more than your bank balance. When developers let non-payment slide, it quietly teaches the market that creative work is optional to pay for. Holding a clear, fair line — you get the work when you've paid for it — defends the value of the whole craft.

And here's the part that surprises people: good clients want this. Clear scope, a sensible deposit, milestone payments, and explicit IP terms aren't red flags to a serious client — they're green ones. They signal a professional who will deliver predictably and won't disappear. The clients you actually want to work with feel safer with structure, not put off by it.

That's exactly how I run engagements now: a clear scope, a deposit, milestones tied to phases, and IP that transfers cleanly on final payment — so the good clients get a smooth, low-risk experience and I never have to make that hard call again. If that's the kind of partnership you're after, here's how to work with me.

FAQ

How much deposit should a freelance web developer ask for?

30–50% upfront is standard for custom work. It covers your downside if the project stalls and signals mutual commitment. For larger builds, break the remainder into milestone payments rather than one big final invoice.

Can I take down a website if the client hasn't paid?

If your contract states that IP transfers only on full payment and you control the deployment, then yes — withholding launch or taking down a deploy you own is exercising your contractual rights, not sabotage. The key is having that clause in writing before you start. Confirm specifics with a lawyer in your jurisdiction.

What should be in a freelance web developer contract?

At minimum: scope and deliverables, payment schedule with triggers, revision limits, IP/usage rights that transfer on full payment, late-payment terms, and termination conditions. A reusable template drafted once by a lawyer pays for itself fast.

When should I just walk away from an unpaid invoice?

When the time, stress, and cost of chasing outweigh the balance — and you've already protected your work (withheld handover, kept IP). Cutting losses with your craft and dignity intact is a valid business decision, not a defeat.

---

If you're choosing a developer and want one who runs clean, predictable engagements, you might also find these useful: how to hire a creative developer, what a creative developer actually is, and — for studios — how white-label creative development works. For an authoritative starting point on contracts and chasing payment, the Freelancers Union resources are a solid, non-legalese reference.