The Freelance Contract and Scope of Work Checklist

You do not need a twenty-page agreement. You need seven things named clearly and a record that both sides agreed to them. The clauses that matter, how to write exclusions that prevent an argument rather than start one, what “IP transfers on final payment” means in practice, and what to send the client who will not sign anything.

Most freelancers do not lose money to dishonest clients. They lose it to projects where nobody wrote down what “done” meant, and a reasonable disagreement had nothing to settle it against. A scope of work is the cheap fix, and it does not need to be long: seven things named clearly, agreed in writing, is enough to prevent most of what goes wrong. This guide covers those seven, how to phrase the awkward ones, and what to do when a client will not sign anything. One thing up front: this is general orientation, not legal advice, and the closing section says what to do about that.

Your email trail is already a record. A handshake is not.

There is a common belief that without a signed PDF you have nothing. That is not quite right, and the distinction is worth understanding because it changes what you do on a Tuesday afternoon with a client who is allergic to paperwork.

What any later process — a platform dispute, a lawyer's letter, a court — works from is evidence of what both sides agreed. A written exchange in which you set out the deliverables, the price and the timeline, and the client replied “yes, go ahead”, is evidence. A phone call in which you agreed the same things is not, because nothing about it can be shown to a third party. So the practical rule is simple: whatever you agree verbally, write down and send, and get a reply. Whether a particular exchange amounts to an enforceable contract depends on the facts and on the law where each of you is — a real question, and one for a lawyer rather than an article.

Keep the record where the project lives. Terms agreed in the platform's messages sit alongside the milestone that was funded and the files that were delivered, which is exactly the bundle that decides a dispute; the same conversation held in a private chat that either side can delete is worth considerably less. This is also why moving a negotiation off-platform costs you more than it saves.

The seven things a scope of work should name

This is the checklist. On a small project it fits on one screen; on a large one each item grows a paragraph. What matters is that none of the seven is missing, because every one of them is something two reasonable people can picture differently.

1. Deliverables. What the client receives, itemised, in nouns they can picture: “five page designs as Figma files plus exported assets”, not “design work”. If a line is a noun you cannot picture finished, it needs breaking down.
2. Exclusions. What is explicitly not included. The single highest-value item on this list, and it gets its own section below.
3. Revisions. How many rounds of feedback are included per deliverable, and what a round means. “Two rounds” with no definition of a round is half a clause; “two rounds, where a round is one consolidated set of feedback” is a whole one.
4. Timeline and dependencies. Your dates, and what they depend on from the client — copy, photos, access, approvals. State the relationship plainly: if a dependency arrives late, the dates move by the same amount. This is the clause that stops you carrying someone else's delay.
5. Payment schedule. Amounts, and what triggers each one. Tie payments to delivered and approved milestones rather than to calendar dates, so neither side is paying or working ahead of the other.
6. Intellectual property. Who owns the output and when ownership passes. Covered in its own section below, because “obviously it's theirs, they paid for it” hides several real questions.
7. Termination. How either side ends it early, and what happens to work already done and money already paid. Nobody enjoys writing this. It is the clause you will be most grateful for, because the projects that end badly are exactly the ones where nobody agreed how to stop.

Writing exclusions that prevent an argument instead of starting one

Freelancers avoid exclusions because a list of things you will not do reads as hostile. The trick is that it only reads that way when it appears in isolation. Framed as clarification, and paired with an offer, it reads as competence — and clients who have been burned before will recognise it immediately as the work of someone who has finished projects.

Three features make that paragraph work. It gives a reason (“so we are working from the same picture”) rather than a rule. It names specifics rather than generalities, so it cannot be argued around. And it offers to do every excluded item, which converts what could read as a refusal into a menu — and quite often into additional work. The items worth listing are the ones you have been caught by before: content, images, hosting, third-party accounts, training, documentation, data migration, and support after handover. Write it once and reuse it.

How a funded milestone changes the advance conversation

The traditional protection against non-payment was an advance: take a share up front, and your downside is capped. It works, but it asks a client who has never met you to move first, which is why the negotiation is often uncomfortable and why the answer is frequently no.

A funded milestone comes at the same problem from the other direction. Before you start, the client commits on the record to a stated amount for a stated deliverable, and that amount is released to you when the deliverable is approved. Clients agree to it far more readily than to an advance, because nothing is being handed to a stranger for nothing yet. Be clear-eyed about what it is, though: on LanceGuru today, funding a milestone records that commitment rather than collecting the money into a provider-held balance, so what you have is dated evidence of what was agreed — not cash already sitting somewhere with your name on it. What it covers and what it does not is set out from the client's side in milestone payments and escrow for clients, and it is worth reading so you can explain the mechanism accurately to someone using it for the first time. The practical consequence for you is unchanged: never begin work on an unfunded milestone. Not because clients are dishonest, but because the funding step is where a vague intention becomes a specific, itemised, dated commitment, and work done before it is work done on nothing.

What “IP transfers on final payment” actually means

This phrase gets pasted into agreements more often than it gets understood, and the details differ by the kind of work you do. The principle is reasonable: the client commissions the work, and on full payment the rights in what you made for them become theirs. The questions are about the edges.

• What exactly transfers? For code, is it the delivered application, or also the internal library you have reused across eleven projects? For design, is it the final logo, or every rejected concept? Name what transfers and what you retain, because reusable tooling you built before this project is normally yours and is worth saying so.
• Third-party components. Almost nothing is built from nothing: fonts, stock images, plugins, open-source libraries. You cannot transfer rights you never had. State that third-party components are licensed rather than assigned, and that the client is responsible for maintaining any licence in their own name going forward.
• Source files or output? Layered design files, project files and source code are a different deliverable from a flattened export or a built site. Say which the client is getting. If source files are extra, that is a legitimate position — but it must be in the scope, not a surprise at handover.
• Portfolio rights. You will want to show the work. Ask for permission to display it in your portfolio, and agree any confidentiality period. Clients almost always say yes when asked at the start and sometimes say no when asked at the end.
• Drafts and rejected work. If the client pays for two concepts and picks one, what happens to the other? Either answer is fine. An unstated answer is how the same rejected concept turns up on a competitor's site and there is nothing to point to.

The load-bearing half of the phrase is on final payment. Ownership passing only when you have been paid in full is what gives the clause its protective function, so keep it explicit. It also means you should be able to say, without embarrassment, that work delivered but unpaid has not transferred.

The client who will not sign anything

This is common, usually harmless, and rarely a sign of bad faith. Plenty of small businesses have never signed a contract with a supplier and find the request alarming, as though it implies a lawsuit is being planned. Pushing harder tends to lose the project rather than win the clause.

So lower the bar instead of the standard. Send the same seven items as a plain email with a subject line like “Scope and terms — please confirm”, in short paragraphs, with no legal register at all, and end with one sentence: “If this matches your understanding, just reply confirming and I will get started Monday.” A reply saying yes is a record. Most clients who refuse to sign a document will happily reply to an email, because it does not feel like a legal act — and the second half of that is a good thing: a written confirmation is far better than nothing, and what it is worth legally is a question for your lawyer rather than a claim to make here.

There is a point at which to stop, though. A client who will not confirm scope in writing in any form, who cannot say what “done” means, or who declines to fund a milestone while asking you to begin, is telling you something. That is not paperwork reluctance, it is an unwillingness to be held to anything, and the cost of finding out later is a month of your capacity. Walking away from one such project a year is cheaper than finishing it.

Documenting scope on work that has already started

Sometimes you read this in week three, mid-project, with nothing written down. You can still fix it, and you can do it without a confrontation, because the framing that works is not “we need a contract” but “let me make sure I have this right.”

Send a summary rather than a demand. Write down what you now understand the deliverables, exclusions, revision count, dependencies and remaining payments to be, based on everything discussed so far, and ask them to correct anything wrong. Nothing about that message is adversarial — you are doing the client a service, and they will usually read it as diligence. It also tends to surface the mismatch while it is still small, which is the entire point.

Where the work has already grown beyond what you priced, name it in the same neutral register and attach it to the future rather than the past: “a few things have been added since we started — the extra two pages and the second round of revisions on the logo. Rather than absorb them quietly, here is what I would suggest for the rest of the project.” Then give the remaining work its own milestone and price. Arguing about the last three weeks is unwinnable; repricing the next three is routine. If you are unsure what the additional work should cost, the arithmetic in setting your freelance rates is the place to start, and remember to factor in the commission on your plan, which is published on the pricing page, when you decide what to quote.

Keep one template, and get it reviewed once

Write your scope of work once, as a reusable document with blanks. Every project then costs you fifteen minutes of filling in rather than an hour of drafting, which is the only reason you will actually keep doing it. Keep the exclusions list and the IP paragraph as standing text you edit rarely, and put the deliverables, dates and payment schedule in the blanks. It is also worth reading how the platform sequences funding, delivery and release — set out on how it works — so your template matches the mechanism rather than fighting it.

Then get the template looked at properly, once. Contract law, what is enforceable, how intellectual property assignment must be worded, what a termination clause can and cannot do, and how any of it applies to a client in another country are all matters that depend on your circumstances and that change over time. Nothing in this article is legal advice, and a checklist cannot be, however carefully written. Have a qualified lawyer review your standard scope of work and terms before you rely on them — one session on a document you will send a hundred times is among the cheapest professional fees you will ever pay, and it is the difference between a template that reads well and one that holds.

The takeaway: write down whatever you agree verbally and get a reply, because a record is what every later process works from. Name seven things: deliverables, exclusions, revisions, timeline and its dependencies, payment schedule, IP and when it transfers, and how either side ends it early. Frame exclusions as clarification and offer to quote each one separately. Never start work on an unfunded milestone. If a client will not sign, get a plain email confirmation instead — and have a qualified lawyer review your standard template once before you rely on it.