How to Write a Freelance Contract (Step-by-Step Guide)
Verbal agreements work great until something goes wrong. Then they become "I thought you meant" conversations that cost time, money, and the client relationship.
A freelance contract isn't a sign that you don't trust the client. It's a shared document that protects both parties and eliminates ambiguity before it becomes a dispute. The sooner you treat it as a standard part of your workflow — not a formality reserved for difficult clients — the fewer problems you'll deal with.
Why Verbal Agreements Always Fail
Verbal agreements have one fatal flaw: memory is selective.
You remember agreeing to two revision rounds. The client remembers "as many as needed." You remember the final payment was due on delivery. The client remembers 30 days after delivery. Neither of you is lying — you just interpreted the same conversation differently.
This is not a hypothetical. It's how most freelance disputes start. The ambiguity isn't malicious — it's structural. When there's no written record, both parties default to the interpretation most favorable to them.
A contract removes interpretation from the equation. It replaces "what did we agree to" with "what does the document say."
Beyond individual projects, contracts establish you as a professional. Clients who work with experienced freelancers expect a contract. Clients who seem surprised or resistant to signing one are often showing you a red flag worth noticing.
What Every Freelance Contract Must Include
Scope of Work
This is the most important clause in any freelance contract — and the most commonly underwritten one.
Scope of work should describe exactly what you're delivering: the number of deliverables, the formats, the number of revision rounds, what's explicitly not included, and any dependencies (what the client needs to provide and by when).
The more specific, the better. "Website design" is not a scope. "Five-page website design in Figma, including homepage, about, services, contact, and blog listing — delivered as high-fidelity desktop and mobile mockups with 2 rounds of revision" is a scope.
Vague scope is the leading cause of scope creep. Every request a client makes outside a specific scope is either a change order or a free gift. With a written scope, you always know which one.
Payment Terms
Specify:
- Total project fee or hourly rate
- Payment schedule (e.g., 50% upfront, 50% on delivery)
- Payment method and due date
- Late payment fee (typically 1.5–2% per month on overdue balances)
- What happens if a client goes dark mid-project (kill fee clause)
The kill fee clause is one most freelancers skip and later regret. It states that if the client pauses, cancels, or indefinitely delays the project after work has begun, they owe a percentage of the remaining fee — typically 25–50%. This protects you from half-finished projects that tie up your time and pay nothing.
Revision Policy
Define the number of revision rounds included and what constitutes a revision vs. a new direction. Common language: "Two rounds of revisions are included. A revision is defined as modifications to the existing design direction. A change in project scope or creative direction will be scoped as additional work."
Without this, "just one more small change" becomes a loop you can't exit.
Intellectual Property and Ownership
Who owns the work product? When does ownership transfer? The answers depend on your arrangement:
- Most freelancers transfer full IP rights to the client upon final payment
- Some retain ownership until payment and license usage until then
- Work created for hire typically transfers fully — make sure the contract states this clearly
If you retain any rights (portfolio use, case study use), document that too.
Confidentiality
If you're working with sensitive client information — business strategy, unreleased products, financial data — a confidentiality clause protects both parties. Even if the client doesn't ask for it, including it demonstrates professionalism.
Red Flags in Contracts Clients Send You
Sometimes clients send their own contract instead of signing yours. Watch for:
Unlimited revisions — any contract language that gives clients unlimited change requests with no fee adjustment is a liability. Counter with your standard revision language.
IP transfer without full payment — some contracts attempt to transfer ownership of your work before you've been paid in full. Don't accept this. Ownership should transfer on final payment.
Unilateral termination without compensation — a client should be able to cancel a project, but they should owe you for work completed plus a kill fee. Contracts that let clients walk away with no obligation expose you.
Payment 60–90 days after delivery — net-60 and net-90 terms are standard in large corporate contracts. They're not standard for freelancers. Push back for net-15 or net-30.
How to Use a Contract in Practice
Once you have the clauses right, the workflow is simple:
- Send the contract before any work begins — ideally alongside the proposal
- Collect a signed copy (e-signature works; no printing required)
- Keep the signed copy on file for every project
- Reference it if any disputes arise — "Let me pull up our agreement" is a lot easier with a document in hand
Never start work before the contract is signed and the deposit is received. This is the single most common mistake that leads to unpaid invoices and scope disputes.
The Freelance Contract Template Pack includes templates for project-based work, retainers, and hourly arrangements — all in plain English, covering every clause above. Customize the scope section for each project (the rest stays the same), send for signature, and file it.
The goal is a document that leaves no room for "I thought you meant." Once you have that, you can focus on doing the work — which is what you're actually being paid for.
Related reading:
- Freelance Contract Red Flags to Watch For — what to look for in contracts clients send you
- How to Handle Scope Creep as a Freelancer — when scope expands despite a solid contract
- Freelance Client Communication Best Practices — setting expectations before problems start