Freelance Contracts: What to Put in Writing Before You Start Work

“Sounds good, let’s get started” is not a contract. It’s the sentence that shows up right before a freelancer spends three extra weeks on unpaid revisions, delivers a final file the client refuses to pay for, or finds out the client considers the work theirs to resell without ever mentioning it during the pitch. None of that requires a dishonest client. Most disputes come from two people who genuinely remembered the conversation differently, because nothing was written down to check against.

A contract isn’t about distrust. It’s the document both people point to when memory gets fuzzy three weeks into a project, which happens on almost every project, regardless of how well it started.

Why Freelancers Skip Contracts, and Why That Backfires

Most freelancers who work without a contract don’t do it because they think it’s a good idea. Surveys from freelancer advocacy organizations point to a consistent set of reasons: fear that asking for a contract will make them look difficult and scare off the client, not knowing which clauses actually matter, or assuming the project is too small to bother with paperwork. The uncomfortable pattern researchers keep finding is that clients who push back on signing a contract are disproportionately the same clients who later dispute the scope or delay payment. Asking for a contract doesn’t just protect you after something goes wrong. It filters out a category of client before the work even starts. This connects to something covered in the questions every freelancer should ask before taking a project — a contract request is itself one of those early filters. A serious client expects it. A client who treats a basic written agreement as an insult to their trustworthiness is telling you something true about how the rest of the project will go.

The Scope: Where Every Contract Actually Starts

Every other clause in a freelance contract depends on this one being specific. A vague scope makes payment terms, revision limits, and timelines meaningless, because there’s no fixed thing to measure any of them against. A scope clause that actually protects you names deliverables in concrete terms: not “website design” but “homepage layout, five interior page templates, mobile-responsive versions, delivered as source files plus exported assets.” Just as important is naming what’s explicitly not included. This is the exact mechanism behind how scope creep actually happens — it rarely arrives as an obvious new project. It arrives as “can you just also add,” one small addition at a time, until an entire second project has been delivered inside the price of the first one. A written scope with clear exclusions is what lets you point at the document and say “that’s outside what we agreed” without the conversation turning into a disagreement about who remembers what.

Payment Terms: The Clause That Actually Gets Enforced

Late and unpaid invoices are one of the most common problems freelancers report, and a written payment clause is the single strongest tool for preventing it. A functioning payment clause should specify the total fee, the payment schedule (a deposit before starting is standard practice for a reason), the payment method, and a specific late fee with a defined percentage and grace period, rather than a vague “payment expected promptly.” For longer projects, milestone-based payments tied to specific deliverables reduce the risk of doing months of work before finding out payment isn’t coming. This is directly connected to how freelancers actually get paid — the payment method matters, but the written terms around when and how much matter more, because a payment method with no enforceable schedule attached to it still leaves you exposed to indefinite delay.

The Kill Fee: Protection If the Project Gets Cancelled

A kill fee, sometimes called a cancellation fee, compensates you if a client cancels a project partway through. Industry practice generally puts kill fees somewhere between 15% and 30% of the remaining contract value, with 20% being a common default in creative and technical freelance work. Without this clause, a client can walk away mid-project after weeks of your time and owe you nothing beyond whatever milestone was already invoiced, which can mean substantial uncompensated work.

Intellectual Property: Who Actually Owns the Work

Under general intellectual property principles, the person who creates a work typically holds the rights to it by default, unless a contract specifically transfers those rights to someone else. This matters more than most freelancers realize going in. Standard practice is to state clearly that full ownership of the deliverables transfers to the client only once payment clears in full, not on delivery. Watch specifically for broad “work made for hire” language that sweeps in more than the named deliverables — your underlying templates, code libraries, or process documents shouldn’t transfer along with the specific project output unless you intend that. It’s also worth explicitly reserving the right to display the completed work in your own portfolio, since some client contracts include confidentiality terms broad enough to accidentally restrict that too.

Revisions: Naming the Limit Before It Becomes a Fight

Revision disputes are one of the most common friction points in freelance work, precisely because “we’ll figure out revisions as we go” sounds reasonable in the pitch stage and becomes a source of real resentment by round six. Naming a specific number of included revision rounds, with a defined per-round fee for anything beyond that, converts an emotional argument about fairness into a simple, agreed-upon number both sides already signed off on.

Confidentiality and Termination: The Clauses People Forget

A basic confidentiality clause, or a short attached non-disclosure agreement, protects both sides when sensitive business information gets shared during a project — client data, unreleased products, internal processes. It doesn’t need to be complicated for most freelance work, but its absence becomes a real problem the one time it’s actually needed. A termination clause defines what happens if either side wants to end the relationship before the project finishes: a required notice period, and what’s owed for work already completed. Without this, ending a bad-fit project cleanly becomes far messier than it needs to be, for both people.

What This Looks Like in Practice

None of this requires a lawyer-drafted, ten-page document for most standard freelance engagements. A one to two page agreement covering scope, payment terms with a late fee, revision limits, IP transfer terms, and a basic termination clause covers the overwhelming majority of disputes freelancers actually run into. The Freelancers Union has published templates and guidance built specifically around these common failure points, and reviewing a template like that before your next project is a faster starting point than drafting one from scratch. If a client offers their own contract instead of using yours, read it with the same checklist in mind rather than assuming standard language protects you by default — the party that drafts the contract tends to draft it in their own favor, which is exactly why having your own version ready to offer first is worth the extra effort. This is also where handling objections without losing the deal becomes relevant: a client pushing back on a specific clause isn’t automatically a red flag, but how they push back tells you a lot about how the working relationship will actually go.

Building This Into How You Work

The freelancers who stop having contract disputes aren’t the ones who found the perfect legal template. They’re the ones who made sending a contract a non-negotiable first step, every single time, regardless of how small the project seems or how well the initial conversation went. This is part of the broader shift covered in thinking like a business owner rather than just someone doing the work — a contract is one of the clearest markers of that shift, because it treats every project as a real business relationship with defined terms, not an informal favor between two people who happen to trust each other today.

---

About the Author
Shurah writes and maintains DataPips independently, drawing on hands-on experience in trading and entrepreneurship. Articles are shaped by personal research, real trading lessons, and the process of building this publication from scratch — not by a formal financial credential.