Payment disputes in freelance work rarely involve fraud. They involve two people with different, sincerely held beliefs about what was agreed, and no document that settles it. The structures below exist to make that disagreement impossible rather than to catch bad actors.
The asymmetry both sides feel
You worry about paying for something you never receive. The freelancer worries about delivering something they are never paid for. Both concerns are legitimate and both have happened to enough people that the caution is earned. Every good payment structure is an attempt to make neither side go first.
Escrow, and why it is the default answer
Escrow means the money leaves your account and is held by a third party before work starts, then released when the deliverable is accepted. You are not exposed, because the funds are not released until you approve. The freelancer is not exposed, because they can see the money is committed.
The part people miss is that escrow only works if the release condition is defined. "Release on completion" is not a condition if the two of you disagree about what completion means. Tie each escrow release to a specific, checkable deliverable written down before work starts.
Worth noting: Never move a conversation off a platform to avoid its fees if escrow is the reason you were using it. The fee is the price of the protection, and the request to move off-platform is the most common precursor to a dispute nobody can arbitrate.
Milestones that actually protect you
Split anything longer than a couple of weeks into stages. Each stage needs three things: what is delivered, what makes it acceptable, and what it costs. Vague milestones — "design phase", "development" — provide no protection at all, because they cannot be objectively judged complete.
- Bad: "Milestone 2 — build the site. $3,000."
- Good: "Milestone 2 — the five templates from the approved design implemented responsively, passing on current Chrome, Safari, and Firefox, deployed to staging with a URL we can review. $3,000."
The second version can be assessed by someone with no technical knowledge, which is the entire point.
The clause that decides who owns the work
In many jurisdictions, the default is that the person who created something owns the copyright — even when someone else paid for it. Unless your agreement transfers ownership explicitly, you may hold a licence to use the work rather than title to it. For a logo, a codebase, or a set of illustrations, that distinction matters enormously the first time you want to modify or resell.
What the agreement should say, in plain terms: all rights in the deliverables transfer to you on full payment, including the right to modify. Two carve-outs are normal and reasonable to accept — the freelancer keeps rights to pre-existing tools and libraries they brought with them, and they may show the work in their portfolio unless you agree otherwise.
- Full copyright assignment on final payment, stated explicitly
- Source files included in the definition of deliverables, not just exports
- Any third-party assets identified, with their licences named
- Portfolio rights either granted or withheld — decided, not left silent
Access and credentials
Own the accounts from the beginning. The domain, the hosting, the repository, the app store listing, the ad account — all registered to you, with the freelancer added as a collaborator. This is boring, takes twenty minutes, and prevents the single most damaging situation in freelance work: a relationship that ends badly while someone else holds the keys to something you depend on.
Share access through a password manager with a shared vault rather than by email or chat, grant the minimum permission needed, and revoke it the day the engagement ends. Never send credentials in plain text — that is a rule about your own security, not about trust in the freelancer.
What to agree before any money moves
- Scope, including an explicit out-of-scope list
- Milestones with acceptance criteria a non-expert could check
- Payment amounts, timing, and method
- Revision rounds included, and the rate for further ones
- Ownership transfer and portfolio rights
- What happens if either side ends the engagement early
- Response-time expectations on both sides
None of this requires a lawyer for a typical freelance project. A written summary that both parties confirm in a message thread is enormously better than nothing, and nothing is what most projects have.
When something does go wrong
Raise it early, in writing, specifically. "The homepage was due Tuesday and I have not seen it — can you confirm where it stands?" resolves most situations, because most situations are a person who fell behind and is avoiding the conversation. Waiting three weeks and then escalating turns a recoverable delay into a dispute.
If it does become a dispute, the platform can only arbitrate on what is documented. Keep the agreement, the deliverable descriptions, and the substantive decisions in written form on the platform rather than in calls. This is not distrust — it is the difference between having a case and having a recollection.