10 Red Flags in Freelance Contracts(and How to Fix Each One)

This is one of the most dangerous clauses in any freelance contract. On the surface it sounds reasonable — the client wants to own the work you create for them. But the phrase "pre-existing materials" is what makes it a trap.

If you build websites, that clause could assign your reusable code libraries to the client. If you're a designer, it may transfer your Figma templates, icon sets, and frameworks you spent years developing. If you write, it could cover your research process, your outline methodology, even your personal notes.

An IP assignment should cover only the specific work product delivered under this contract — not your entire toolkit. Most freelancers don't catch this distinction, and once you've signed it, unpicking it is expensive.

A two-year non-compete for a freelancer is extraordinarily aggressive. Unlike employees (who at least have salary during the restriction period), freelancers have no income protection. A clause like this could make it impossible to work in your industry for two years — without a cent of compensation.

The words "directly or indirectly" and "any business" make it even broader. A web developer working for a marketing agency could be blocked from working for any other marketing agency, any tech company, potentially any company at all.

Non-solicitation clauses (preventing you from working with the client's other contractors, employees, or clients) are often buried in the same section. Many are unenforceable — especially in states like California — but signing one creates legal risk and cost even if you ultimately win a challenge.

"Until Client is satisfied" is not a deliverable — it's a blank check. There is no contract in the world that can guarantee client satisfaction, and open-ended revision clauses routinely cost freelancers hundreds of unbilled hours.

The practical danger is scope creep disguised as revision. A client asks for "a few small changes" — which turn into a full redesign. With unlimited revisions baked into the contract, you have no contractual ground to stand on when billing for extra work.

This clause also creates perverse incentives: a client who is slow to make decisions or has unclear internal alignment can use unlimited revisions to delay sign-off indefinitely, keeping you on the hook while they figure out what they want.

Waiting three months to get paid is unsustainable for most freelancers. Net-90 terms were designed for large corporate supply chains with access to credit facilities — they have no place in a freelance contract.

What makes this even worse is the phrase "upon acceptance." If the client gets to decide when they've "accepted" the invoice, they can delay acceptance — and therefore payment — indefinitely. Combined with subjective acceptance criteria, Net-90 can effectively become "we'll pay you whenever we feel like it."

The hidden cost: if you're mid-project with Net-90 terms, you may be weeks into new work before you receive payment for the previous phase. For many freelancers, this means going weeks or months without income while still delivering work.

Termination without cause clauses are standard in client contracts for a reason: they give the client maximum flexibility at your expense. You may have turned down other work, bought equipment, or hired subcontractors based on this project. Without a kill fee, you absorb all of that cost.

The "completed and accepted" language is another trap. If a client terminates mid-project and disputes what constitutes "completed" work, you may have difficulty collecting even for hours you've already worked. Some clients use termination-without-cause as a mechanism to avoid paying for work they received.

A kill fee doesn't just compensate you for lost income — it filters out bad-faith clients. Clients who balk at a reasonable kill fee clause are often the same clients who will cancel without warning.

Vague scope language is the single most common source of freelancer disputes. "As reasonably requested" is not a deliverable — it's an invitation to be asked for progressively more work with no additional compensation.

Scope creep rarely happens all at once. It happens incrementally: a small addition here, a "quick change" there, one more feature, just one more page. Each individual request seems reasonable. Cumulatively, they can double or triple the actual work performed under a contract.

Without a defined scope and a change order process, you have no contractual mechanism to push back. The client will always argue that the additional work falls within "services as reasonably requested." Your only recourse is to renegotiate informally — a difficult conversation when you're mid-project and dependent on final payment.

Unlimited indemnification is one of the most financially dangerous clauses a freelancer can sign. It means that if a client gets sued for anything even tangentially related to your work, you may be required to pay their legal defense costs — regardless of fault.

Here's a real scenario: you build a website for a client. The client uses it to make representations that turn out to be false, and gets sued. Under unlimited indemnification, you could be dragged into that lawsuit and required to fund the client's defense, even if the false representations had nothing to do with your work.

One-sided indemnification clauses (where only you indemnify the client, not vice versa) are particularly common in large-company contracts. They treat the freelancer as having unlimited liability exposure for a fixed, often modest fee.

This clause structure — client liability capped at 30 days of fees, contractor liability unlimited — is disturbingly common in enterprise freelance contracts. A project worth $10,000 could expose you to liability worth millions if something goes wrong.

What "something going wrong" looks like in practice: you deliver work, the client deploys it, it has a bug that causes a system failure, the failure causes a business disruption, and the client claims millions in lost revenue from you. Without a liability cap, that's theoretically your exposure.

The 30-day cap for the client is particularly absurd: if the client owes you $15,000 in unpaid invoices, their maximum liability under this clause is whatever you invoiced in the last 30 days — potentially just $5,000.

The "work for hire" doctrine is one of the most misunderstood areas of freelance contract law. Under U.S. copyright law, work created by an employee within the scope of employment is automatically "work made for hire" — the employer owns it. For independent contractors, it only applies to specific categories of work and must be expressly agreed in writing.

The double assignment clause (work for hire + fallback assignment) ensures the client gets ownership no matter what. That's not inherently wrong — but it means you can't reuse elements, reference the work as yours for copyright purposes, or license it elsewhere without the client's permission.

The portfolio risk is real: some work-for-hire agreements prevent you from displaying the work publicly. Make sure your contract explicitly preserves your right to include the work in your portfolio, especially if the client has confidentiality concerns.

This combination is the most dangerous clause structure in freelance contracts. The client gets your IP the moment you sign — and then can fire you without paying, without warning, without cause.

Conditioning IP transfer on full payment is standard commercial practice (it's how most purchase agreements work), but many freelance contracts written by clients reverse this entirely. The logic they use: "We need to own the IP to ensure we can use the work." That's legitimate — but it doesn't require transferring ownership before you're paid.

A conditional transfer protects you without changing the ultimate outcome for a fair-dealing client. If the client is paid in full and the relationship ends normally, they get the IP as expected. The clause only "activates" when the client tries to take your work without paying.