The Codex

Freelance contracts: the clauses that matter

A good contract does three things: defines scope, defines payment, and defines what happens when reality changes.

Contracts & LegalStartRunGrow24 min

Freelancers don't usually get burned because they forgot a semicolon. They get burned because reality changed and the agreement didn't say what to do next.

  • The client adds stakeholders mid-project.
  • The scope expands because "it's just a small change."
  • Legal sends a contract with unlimited liability.
  • Procurement insists on Net 60.
  • The project stalls in review.
  • The client is late paying but expects you to keep working.

A good freelance contract is not "fancy paperwork." It's a risk-management tool that makes those moments boring.

This guide is a clause-by-clause map of what actually protects you: scope boundaries, change control, payment terms, IP, confidentiality, liability limits, termination, and the red flags that tell you to slow down or walk away.

Disclaimer: This is educational information, not legal advice. Laws and enforceability vary by jurisdiction and context. For high-stakes contracts, consult a qualified lawyer in your jurisdiction.

If you want templates to apply this immediately:

If your pain is primarily late payment, also read:

Codex summary

A good contract does three things: defines scope, defines payment, and defines what happens when reality changes. Use a SOW with clear boundaries, run change requests as a process, set payment terms that match your risk, cap liability, and define termination so you can exit safely.

Who this is for

Freelancers who have been burned by scope creep, late payment, scary liability language, or unclear IP.

If you only do 3 things

  1. Attach a SOW with scope boundaries. The SOW is where "definition of done" lives.
  2. Use payment terms that match your risk. Deposits, milestones, due dates, and work pause rights.
  3. Cap liability and define termination. Unlimited liability and vague termination terms are common freelancer-killers.

Who this is for

This page is for freelancers who:

  • have been burned by scope creep
  • get paid late and don't know what to enforce
  • receive client contracts with scary liability language
  • aren't sure what happens to IP/ownership
  • want to negotiate without starting a fight
  • need a "minimum viable contract" that works in real life

If you work with enterprise clients, you'll also benefit from the negotiation section (enterprise contracts often include default clauses that are unreasonable for solo providers).

Contract basics: what documents are we talking about?

Freelance engagements commonly include some combination of:

Master agreement (MSA) or services agreement

A general agreement that covers legal terms: liability, confidentiality, IP framework, dispute resolution.

Statement of Work (SOW)

The project-specific document: deliverables, scope, timeline, payment schedule, assumptions, and boundaries.

This is where most freelancer pain lives, which is why we treat the SOW as essential:

NDA (non-disclosure agreement)

Sometimes separate, sometimes integrated. NDAs vary widely. Most freelancers need a reasonable NDA with standard carve-outs.

Change order / change request addendum

When scope changes. This is how you make "just one more thing" boring:

You can do freelancing with "one document" if you must, but it should still contain: scope, payment, change control, IP, liability limits, termination. A two-document approach (agreement + SOW) is often cleaner.

The clauses that matter (and why)

Below is the practical clause map. You do not need every clause in the universe. You need the clauses that cover the failure modes you're likely to experience.

1) Parties, names, and definitions (boring but important)

Make sure the agreement identifies:

  • the legal client entity (not just a brand name)
  • your legal name/entity (if applicable)
  • and key definitions (e.g., "Deliverables," "Confidential Information")

This matters most when invoices go to the wrong entity or the signer doesn't match who pays.

2) Scope: deliverables and "definition of done"

Scope is the number one freelancer conflict source. A good scope clause answers:

  • What exactly will be delivered?
  • What does "done" mean?
  • What is explicitly out of scope?

Out-of-scope is not rude; it is clarity.

Best practice: define scope in the SOW, not buried in email.

Use: Statement of Work (SOW) Template

Example: "definition of done" (plain language)

"Landing page redesign delivered as Figma file + exported assets. Includes up to two revision rounds. Does not include development/implementation unless explicitly listed."

Notice how it names revision limits and excludes implementation. That prevents "We assumed you'd build it."

3) Timeline, review windows, and approvals

Most delays are not your work speed. They're review cycles.

Protect yourself with:

  • milestone dates
  • review windows ("Client will respond within 3 business days")
  • what happens if the client delays (timeline shifts accordingly)

This is also a retention and sanity tool: Onboarding, delivery, and retaining clients

4) Client responsibilities (inputs, access, decision-maker)

Freelance projects stall when the client doesn't provide access, assets, or approvals.

A strong clause includes:

  • what inputs are required
  • by what date
  • and that the client assigns a single decision-maker

If client responsibilities are vague, you become responsible for their internal chaos.

5) Acceptance criteria and revisions

Acceptance criteria prevents infinite "tweaks."

Include:

  • what counts as acceptance
  • how many revision rounds are included
  • how additional revisions are priced (hourly, change request, new milestone)

This is where you convert "creative feedback loops" into bounded work.

6) Change control: the scope creep kill switch

Change control is the clause that saves relationships. Without it, every change request becomes personal.

Change control says:

  • Anything outside scope is a change request
  • Provider estimates time/cost impact in writing
  • Work begins only after written approval

Use: Change Request Addendum Pack

This is also how you avoid "death by small changes."

7) Fees and payment terms (the oxygen clause)

A payment clause should answer:

  • How much? (fee structure)
  • When? (billing schedule + due dates)
  • How? (payment method)
  • What if late? (follow-ups, late fees where allowed, work pause)
  • Who pays fees/expenses? (if relevant)

If you are regularly paid late, your contract probably lacks enforceable consequences, or you aren't using them.

Start with:

Practical payment terms that reduce risk

  • Deposit upfront for projects (especially with new clients)
  • Milestone billing for multi-week work
  • Shorter net terms when possible (Net 7/14 instead of Net 30/60)
  • Work pause clause for overdue invoices

Work pause clause (concept)

"If invoices are overdue, Provider may pause work until the account is current. Timeline commitments shift accordingly."

This is not about punishment. It is about not financing the client's business.

8) Intellectual property (IP): assignment vs license

Clients often assume "If we paid, we own everything." That is not always legally true, and even when it is, you still want clarity.

Key questions:

  • Is work product assigned to the client or licensed?
  • What pre-existing materials do you retain?
  • Can you reuse templates, frameworks, and general know-how?
  • Can you show the work in your portfolio? (often a separate permission clause)

A common freelancer-friendly pattern:

  • client receives rights to the deliverables they paid for
  • you retain pre-existing materials, templates, and general know-how
  • you may display non-confidential work in a portfolio with permission (or after public release)

Be careful with open-source software and third-party assets: make sure the agreement doesn't accidentally promise "100% original" work if you use common libraries.

9) Confidentiality (NDA language)

Reasonable confidentiality clauses typically include carve-outs:

  • information already public
  • information independently developed
  • information received from another source without breach
  • disclosures required by law

Confidentiality should be workable. If it forbids you from using general skills you learned, it is likely unreasonable.

10) Warranties and disclaimers

Clients sometimes include warranties like "results will be error-free" or "service will meet all requirements."

As a freelancer, you can often commit to:

  • professional and workmanlike services
  • reasonable care
  • delivering the described deliverables

Be cautious about warranties that promise outcomes you can't control (e.g., "increased revenue," "SEO ranking improvements") unless you are explicitly selling that as a guaranteed outcome (rare and risky).

11) Liability caps and limitation of damages

This is one of the highest-stakes clauses for freelancers.

Common enterprise defaults:

  • unlimited liability
  • broad indemnification
  • consequential damages exposure

For a solo provider, unlimited liability can be existential.

A common approach (conceptually):

  • cap liability to the fees paid under the agreement (or a multiple)
  • exclude consequential damages (lost profits, etc.)
  • limit indemnity to specific areas you control (e.g., IP infringement of your original work)

This is jurisdiction-dependent and contract-specific. Consult counsel for serious engagements.

12) Indemnification (who covers what)

Indemnities can be reasonable or wildly risky.

A freelancer-friendly approach:

  • you indemnify the client only for IP infringement of your original deliverables (to the extent you had the right to provide them)
  • client indemnifies you for materials they provide (brand assets, data) if those create claims

Broad "you indemnify us for everything" language is a red flag.

13) Termination (how to exit safely)

Termination clauses matter because projects end early all the time: priorities shift, budgets change, stakeholders leave.

A sane termination clause answers:

  • how either party can terminate (notice period)
  • what happens to fees (payment for work completed to date)
  • what happens to deliverables (handover of what's paid for)
  • what happens to deposits (often non-refundable once work begins, depending on terms)

Without this, you can get stuck doing unpaid work "to finish" a project the client no longer wants.

14) Dispute resolution and governing law

This decides where and how disputes happen. Enterprise contracts may specify a venue that is expensive for you.

In many freelancer relationships, the best solution is: avoid disputes by having enforceable payment and scope systems. But if disputes arise, you want the contract not to make it impossible to enforce your rights.

15) Non-solicit, non-compete, exclusivity

Be careful.

  • Non-competes can restrict your ability to earn.
  • Exclusivity can quietly block you from other clients.
  • Non-solicits can be reasonable in narrow scopes, but sometimes overreach.

If you see broad restrictions, ask why they exist and narrow them. If the client can't justify them, consider walking.

Negotiation: how to push back without turning it into a fight

Negotiation is easier when you frame requests as risk alignment, not personal preference.

Prioritize your redlines

Most freelancers can't win every clause. Pick the clauses that protect your business:

  1. payment terms + work pause
  2. scope boundaries + change control
  3. liability cap + limitation of damages
  4. termination + payment for work completed
  5. IP clarity

Everything else is secondary.

Use "fallback positions"

Instead of "no," use "here's the version that works for me."

Examples:

  • If they insist on Net 60: "I can do Net 30, or Net 60 with a larger deposit/milestones."
  • If they want unlimited liability: "I can accept a cap at fees paid, plus exclusion of consequential damages."
  • If they want vague scope: "I can start with a phase 1 audit, then scope phase 2 after."

Ask for a SOW even if they have an MSA

Enterprise clients often treat the MSA as fixed. The SOW is where you can still protect yourself.

If they say "We don't do SOWs," that's usually a process issue, not a law of physics. Push gently.

Red flags (slow down, clarify, or walk away)

  • "We don't sign vendor contracts for small projects." (If they will not sign, what will they enforce?)
  • Unlimited liability + broad indemnity + low fee. (Asymmetric risk.)
  • Vague scope + urgent deadline + "fixed price" request. (Risk without pricing.)
  • Payment terms that force you to finance the client (Net 90) with no deposit. (Cashflow danger.)
  • No clear decision-maker and chaotic stakeholder set. (Delivery chaos.)

If you see several red flags at once, consider reducing scope to a smaller first phase or walking.

Tools and templates

FAQ

"Do I need a contract for every job?"

You need clear scope and payment terms for every job. A formal contract may be more important as risk increases (bigger fees, longer timelines, sensitive data, enterprise clients). At minimum, use a SOW and clear invoicing terms.

"Can I use a template contract?"

Templates are starting points. The important part is whether the template covers your real failure modes: scope change, late payment, termination, and liability. Use the templates here as a base, and consult a lawyer for high-stakes work.

"What if the client insists on using their contract?"

Common. Focus on negotiating the clauses that matter: payment, scope/change control, liability cap, and termination. Ask to attach your SOW as the scope document.

"What about late fees?"

Late fee enforceability varies by jurisdiction and contract terms. Even if you don't charge late fees, you should still enforce due dates and work pause rights.

Jurisdiction notes

Not legal advice. Contract enforceability varies by jurisdiction and context. For high-stakes contracts (large fees, sensitive data, high liability exposure), consult qualified counsel in your jurisdiction.

Tools and templates

Quote to SOW Checklist

A checklist to turn discovery notes into a scoped quote and a lightweight SOW with boundaries, review windows, and payment terms.

checklist
Open Quote to SOW Checklist

Statement of Work (SOW) Template

A lightweight SOW template that makes scope boundaries explicit and makes change requests boring.

template
Open Statement of Work (SOW) Template

Scope Change Checklist

A change request workflow checklist: clarify the request, estimate impact, get approval, and keep scope changes procedural.

checklist
Open Scope Change Checklist

Change Request Addendum Pack

Short addenda you can attach when scope changes: change request, late fees, and timeline shifts.

template
Open Change Request Addendum Pack

Late Payment Checklist

A checklist for collecting overdue invoices: prevention, follow-ups, work pause, and escalation without making it personal.

checklist
Open Late Payment Checklist

Comments

Sign in to comment.

Loading comments…