P2 · Trying to get paid
Protecting Deliverables Until Final Payment
Protect unpaid work with staged delivery, previews, objective payment triggers, clear IP timing, controlled source-file handoff, and no credential hostage-taking.
The safest leverage is designed into the contract and delivery process before a dispute. Trying to invent ownership restrictions after full source files are already handed over is much harder. For visual work, watermarked or lower-resolution review files can prove progress without releasing production assets. For code, staging environments or restricted repository access can serve a similar approval function.
Make the IP clause and the actual handoff workflow agree
If the contract says a license or IP assignment becomes effective upon full payment, make the handoff workflow match that language. Contract text that is ignored operationally creates confusion.
Release production files only after the final payment trigger
Handoff design: deliver a watermarked final proof on milestone completion, invoice the final 30%, confirm cleared payment, then release production files plus a handoff manifest listing filenames, versions, credentials transferred, and any retained pre-existing components. The process makes payment and ownership timing observable.
Separate client-owned assets from your pre-existing tools and know-how
Separate client-owned materials from your own pre-existing tools, templates, libraries, and know-how. 'No source until paid' cannot justify withholding credentials or property that already belongs to the client under the agreement.
Trigger final payment from an objective delivery event
Final payment should be triggered by an objective event—delivery of final preview, acceptance, or milestone—not a vague feeling that the project is finished.
Payment leverage does not create a right to sabotage a live system
Do not sabotage live systems, revoke essential access, or threaten deletion to force payment. Technical control does not automatically create a legal right to use it as collection pressure.
Build leverage into delivery without harming the client
Payment leverage works best when it is designed into the contract and handoff sequence before anyone is late. For visual work, a watermarked or lower-resolution proof can show completion without releasing production files. For software, a staging environment can demonstrate the result while source repositories, deployment credentials, or production transfer remain tied to the agreed milestone. If the contract says an IP assignment or license becomes effective after full payment, make the actual handoff follow that condition so the paper and workflow do not contradict each other.
Separate client-owned inputs from your pre-existing templates, libraries, code, processes, and know-how. A broad 'all work belongs to client' sentence can create unnecessary disputes if the proposal never defined background materials. Use objective payment triggers—delivery of final preview, a milestone, or acceptance under defined criteria—rather than 'when the project feels done.' Preserve the exact version sent for review and the version released after payment. Do not sabotage a live system, delete client property, or revoke essential access in a way the contract or law does not permit. The strongest leverage is a calm release sequence, not a threat.
Design the delivery sequence so the client can review progress without receiving every production asset before the payment trigger. A designer can use watermarked or reduced-resolution previews; a developer can demonstrate on staging; a writer can share a review document while reserving final formatted/source packages; a video editor can use review links. The method must fit the profession and contract—do not damage deliverables or create artificial barriers after promising unrestricted delivery. State in the proposal and agreement which files are review assets, which are final deliverables, and when each is released. If the client needs source access early for collaboration, price and structure the milestone so the risk is acknowledged rather than relying on technical lockout.
Align intellectual-property language with payment. A common structure is to grant or assign specified final rights after receipt of final payment while the freelancer retains pre-existing tools, know-how, or licensed third-party materials, but copyright and contract rules are fact-specific and legal drafting may be needed. Do not assume withholding files lets you ignore a client’s existing property or credentials. Keep backups and a handoff checklist: final exported files, source files if included, licenses, passwords, documentation, and confirmation of payment. If payment is late, use the contract’s pause and collection process instead of secretly disabling a live site or deleting client data. Technical leverage should support a clear commercial agreement, not replace one.
Use an acceptance receipt at final payment. When funds clear, send a checklist of delivered items and ask the client to confirm access: source files, production credentials, documentation, licenses, and any third-party account transfers. That timestamp protects both sides from later claims that a file was never handed over. Archive a read-only copy of what was delivered and the applicable contract version. If ongoing hosting or maintenance continues, separate those services from the completed project so a later support invoice does not blur ownership of deliverables already paid for. Clear handoff is the end of the payment-control system, not just the moment you email a ZIP file. Confirm which third-party licenses cannot be transferred at all. Fonts, stock media, plugins, and SaaS accounts may have their own license terms, so a contract promise to transfer ‘everything’ can be impossible unless these items are carved out and documented.
Final-payment handoff protocol
- Review copy
Use staging, preview, watermark, low-resolution, or otherwise controlled review assets when appropriate to the service. The client should be able to evaluate the work without receiving every final production asset before the agreed payment event.
- Payment trigger
Define the objective event: invoice paid, cleared funds, milestone accepted plus payment, or another written condition. Avoid vague language such as “upon completion” when client approval and cash settlement can occur on different dates.
- IP/license timing
State when ownership or license rights transfer and carve out pre-existing tools, fonts, stock assets, code libraries, or templates that are not being assigned. U.S. copyright ownership/transfer rules deserve explicit written treatment rather than assumptions.
- Handoff manifest
After the trigger, release the agreed source files, exports, credentials, documentation, and version list; record the exact handoff set. Keep client-owned credentials separate from leverage and archive both the preview and final versions for dispute evidence.
Before releasing production assets
- Tie IP/license timing to the written agreement.
- Use preview or staging for approval.
- Keep client-owned credentials separate.
- Define the objective final-payment trigger.
- Archive the exact final handoff set.
IP and final-payment references
Handoff questions when payment and ownership meet
Can I keep final source files until payment?
If the contract clearly makes final delivery contingent on payment, staged handoff can be a legitimate risk-control design. Use previews or staging for approval and define exactly what is released after the final trigger. Do not retroactively invent restrictions after handing over unrestricted assets.
Does copyright automatically transfer when a client pays?
Not necessarily. U.S. copyright ownership, assignments, licenses, and work-made-for-hire rules are technical and depend on the agreement and work. Put the intended ownership or license language in writing and have important IP clauses reviewed rather than relying on assumptions about payment alone.
What should never be used as payment leverage?
Do not disable live systems, withhold client-owned credentials, delete data, insert malicious code, or otherwise create damage. Commercial leverage should come from the contract and staged delivery, not from interfering with assets the client already owns or controls.
What belongs in a final handoff record?
List the exact files and versions delivered, credentials transferred, licenses or pre-existing components, outstanding third-party items, and the payment event that triggered release. A dated manifest prevents later arguments about whether a source file or access item was omitted.