Web Developer Payment Chase Guide

Staging vs production: your most powerful leverage

Here is the leverage most developers overlook. If you deploy to a staging environment for client review and require payment before pushing to production, you maintain control of the final deliverable. The client can see the work, test it, approve it, and verify it meets the spec, but it is not live until they pay.

Your contract should include language like: 'Development work will be deployed to a staging environment for client review and approval. Deployment to the production environment will occur within [2-5] business days of receipt of the final milestone payment. Consultant retains access to and control of the staging environment until the project is paid in full.'

This is not holding work hostage. It is a standard delivery process used by development agencies worldwide. The staging environment exists so clients can review and approve work before it goes live. Tying the production deployment to payment is a natural part of that workflow.

Code escrow and IP transfer on payment

For larger projects, code escrow gives both parties peace of mind. You deposit the source code with a neutral third party (or a simple GitHub repository with controlled access). The client knows the code exists and is complete. You know it will not be released until payment clears.

Your contract should address intellectual property clearly: 'All source code, designs, documentation, and related materials created under this agreement are the intellectual property of [Developer Name] until full payment is received. Upon receipt of final payment, all intellectual property rights transfer to [Client Name], including access to the source code repository.'

Without this clause, clients may argue they own the code because they paid for it to be developed. With the clause, there is no ambiguity. The transfer happens on payment, not on delivery. If the client does not pay, you own the code, and any use of it by the client is a violation of your intellectual property rights.

Hosting and domain leverage: use with caution

If you registered the domain or set up hosting on behalf of the client, you may have administrative access that gives you leverage. But use this carefully. There is a meaningful legal and ethical difference between withholding new work (which is your right) and disrupting a live service (which could expose you to liability).

If the domain is registered in your name: you control it, but the ethical move is to transfer it to the client upon payment. Do not hold it indefinitely. Use it as a negotiation point: 'I am happy to transfer the domain once the balance is settled.'

If you have hosting access: do not take down a live site. Even if you are owed money, taking down a live website can be considered tortious interference with the client's business, and you could end up owing them more than they owe you. Instead, remove your access to the hosting account and let the client manage it going forward. Your leverage is in the source code and future maintenance, not in disrupting their operations.

The safest approach: set up hosting and domains in the client's name from the beginning, with you as an authorized administrator. When the project is paid, you hand over admin credentials. This keeps things clean and eliminates the temptation to use hosting access as a collection tool.

The developer's collection escalation timeline

Day 1 to 7 past due: Send a friendly reminder. Attach the invoice. Assume good intentions. Many developer invoices go unpaid because the client's accounting department does not know who you are or what the invoice is for.

Day 8 to 21: Send a firm follow-up. Reference your contract terms, any applicable late fees, and the IP transfer clause. If the project is on staging, note that deployment to production is pending payment. Be direct: 'I want to get this wrapped up for both of us. Can we get the balance settled this week?'

Day 22 to 45: Send a formal demand letter. State the total owed including late fees, reference the contract, and set a 14-day deadline. Mention that you will pursue legal remedies including small claims court if not resolved. At this point, also remove yourself from any ongoing support or maintenance obligations.

Day 46 and beyond: File in small claims court for amounts under your state's limit (typically $5,000 to $10,000). For larger amounts, consult an attorney. If the client is using your code without having paid, you have both a breach of contract and a potential copyright infringement claim.

Structuring your next project to avoid this entirely

After getting burned once, most developers overhaul their process. Here is the setup that works. Use milestone billing with no more than 25% of the total fee unpaid at any point in the project. Deploy to staging for review and require payment before going live. Include an IP transfer clause that ties code ownership to payment. Set up hosting and domains in the client's name from day one. And require a signed contract before writing a single line of code.

Consider using a project management tool that gives the client visibility into progress without giving them access to the actual code. This builds trust and reduces the 'I cannot tell what I am paying for' objection that leads to many developer payment disputes.

For repeat clients, offer a small discount (5% to 10%) for upfront payment in full. Many clients prefer the simplicity of a single payment, and you get your cash immediately with zero collection risk. A $9,000 project paid upfront is worth more than a $10,000 project paid in four installments over six months.