Theme I Need logomark
Freelance
7 min read

The Freelancer's Guide to Contracts: What to Include Before You Start Any Project

A contract is not a legal formality β€” it is the document that prevents the most common and most expensive freelance disputes. Here is what every project contract needs to include, and why each clause exists.

Man being interviewed by a woman in a formal professional setting
Photo by Gustavo Fring on Pexels

Most freelancers who have been doing this work for more than a year have a story that starts the same way: the client who seemed perfectly reasonable at the outset, who agreed to everything verbally, and who later disputed the scope, delayed payment, or disappeared after the work was delivered. Every version of this story has the same preventable cause β€” the absence of a written agreement that both parties understood and signed before work began.

A contract does not prevent all disputes. It does prevent the most common ones, and it provides the resolution framework for the disputes it does not prevent. Beyond its protective function, a well-written contract communicates to clients that you operate professionally β€” which sets the tone for the entire engagement and filters out, at the proposal stage, the clients who resist written agreements for the same reasons you should want one.

The Scope Section: The Most Important Clause

Every project contract needs an explicit, specific description of what is included β€” and just as importantly, what is not. The scope section is where most contract disputes originate, because vague scope language leaves room for interpretations that the client and the freelancer fill with different assumptions.

A scope that prevents disputes describes deliverables in observable, verifiable terms. Not "design a website" but "design a five-page website consisting of Home, About, Services, Blog, and Contact pages, as detailed in the attached project brief." Not "provide ongoing support" but "provide up to four hours of post-launch support per month for thirty days following delivery, covering bug fixes resulting from design implementation errors."

Include an explicit out-of-scope statement: a brief list of the things most commonly added to this type of project that are not included in the quoted price. For a web design project, this might include copywriting, photography, SEO optimization, hosting setup, and custom illustration. The out-of-scope list signals to the client what to expect when they ask for these things β€” not that they cannot have them, but that they will be quoted separately.

Revision Policy and Approval Gates

Revision expectations are the second most common source of contract disputes after scope. Without a written revision policy, clients believe they are entitled to revisions until they are satisfied; freelancers believe revisions beyond a reasonable number warrant additional fees. Both beliefs can be simultaneously held in good faith, which makes the dispute particularly frustrating.

A revision policy specifies the number of included revision rounds per deliverable, what constitutes a revision round versus a new direction, and the rate for additional rounds beyond what is included. A revision round is a consolidated set of feedback delivered at once β€” not a series of individual changes sent incrementally over days. This definition prevents the scenario where a client treats the feedback process as an ongoing back-and-forth with no defined endpoint.

Approval gates β€” formal sign-off points at defined stages of the project β€” do two things. They create clear milestones where the client affirms direction before work proceeds further, which prevents the expensive situation of completing a project in the wrong direction. And they establish a paper trail of approvals that makes the final scope less disputable.

Payment Terms That Protect Your Cash Flow

The payment section should specify the total project fee, the payment schedule, the due dates for each payment, the accepted payment methods, and the consequences of late payment.

A deposit β€” typically thirty to fifty percent of the project total β€” due before work begins is a non-negotiable for any significant freelance engagement. The deposit serves several functions simultaneously: it filters out clients who are not serious about the project, it funds your early work before invoices are due, and it creates a financial stake in the project that changes the client's behavior throughout the engagement.

The remaining payment structure depends on project length and your cash flow needs. For shorter projects, a fifty percent deposit and fifty percent on delivery is common. For longer projects, milestone-based payments β€” tied to specific delivery dates or approval gates β€” reduce the gap between work performed and payment received. Avoid net-sixty or net-ninety payment terms for small projects; net-fourteen or net-thirty is standard and appropriate for most freelance engagements.

Include a late payment provision: typically one to three percent per month interest on unpaid balances after the due date, plus the right to pause or terminate work if payment is not received within a defined window. Most clients never trigger this provision. Its presence in the contract signals seriousness and occasionally prompts faster payment from clients who might otherwise let invoices drift.

Intellectual Property and Ownership Transfer

Without an explicit IP clause, the ownership of work created during a freelance engagement is governed by copyright law β€” which in most jurisdictions defaults to the creator, not the client, for contractor work. Most clients assume they own the work the moment they pay for it. Most freelancers assume the same. Both are often wrong about what the law actually says.

A standard IP clause for most freelance creative work specifies that ownership of all original work transfers to the client upon receipt of full payment. This is the outcome both parties typically want β€” the clause makes it explicit and ties ownership transfer to payment, which provides leverage for collecting outstanding invoices.

Reserve the right to use the work in your portfolio unless the client has a legitimate confidentiality requirement. Portfolio rights are standard and most clients do not object, but the objection is much harder to handle after the project is complete than if it is addressed in the original agreement.

Termination and Kill Fee

Every project contract should address what happens if the engagement ends before completion β€” initiated by either party. Without a termination clause, this scenario produces unpredictable outcomes that favor whichever party is willing to be more aggressive.

A kill fee is a payment the client owes if they terminate the project without cause. Typically calculated as a percentage of the remaining contract value or a fixed minimum, it compensates the freelancer for the work completed, the opportunity cost of the reserved time, and the disruption of the pipeline. Kill fees are not punitive β€” they reflect the real cost the freelancer incurs when a project terminates unexpectedly.

Include a clause governing your right to terminate as well: specifically, the right to stop work and retain payment for work completed if the client breaches the contract's terms β€” by failing to pay on schedule, by failing to provide necessary materials within a defined window, or by requesting work that falls outside the agreed scope without agreeing to a change order.

Sending the Contract

Send the contract before beginning any work, including any preliminary or exploratory work that might reasonably be expected to produce billable output. The signed contract is the starting gun, not a formality completed after work is underway.

Use a digital signature tool β€” DocuSign, HelloSign, or similar β€” that timestamps signatures and stores the executed document securely. The signed PDF stored in your email is not a reliable legal record. A properly executed digital agreement with a verifiable audit trail is.

The contract that protects you most is the one that is signed, in full, before the first deliverable is created. The second most important time to have it is right now, before the next project begins.