How to Use Contracts to Define Deliverables

A freelance contract is only as useful as its deliverables section. The rest — payment terms, kill fees, IP clauses — matters too. But scope is where most freelance disputes begin.

When a client says “you didn’t deliver what we agreed,” and you say “yes I did,” what settles the argument? The contract. Specifically, what it says about deliverables.

Here’s how to write that section so it actually protects you.

Why Deliverables Are Where Contracts Fail Most Often

Most freelancers understand the basics. Put payment terms in writing. Include a termination clause. Get a signature.

But they write the deliverables section too loosely. “Design a website” isn’t a deliverable. It’s a category. Without specifics, both sides fill in the gaps with different assumptions — and then fight about it later.

Miguel, a web designer from the Philippines, once had a dispute with a client over what “a website” meant. His contract said “five-page website.” The client assumed this included a blog with ten posts, a shop, and an events calendar. Miguel assumed it meant five static pages.

Neither was lying. The contract was just vague.

The fix wasn’t a better lawyer. It was a more specific deliverables section.

What a Deliverables Section Should Include

Think of your deliverables section as a precise description of the finished product. When you’re done, both you and the client should be able to look at that description and independently agree that the work either meets it or doesn’t.

Specific Outputs

Name every deliverable clearly. Not “website” but:

• Home page (desktop and mobile responsive)
• About page
• Services page (three service tiles with individual detail sections)
• Contact page with embedded form
• Blog index page (design only, no content)

Not “copywriting” but:

• Homepage copy: hero section, three benefit sections, one CTA section (~600 words total)
• About page: bio section + values section (~400 words)
• Two blog posts: [specific topics, ~800 words each]

The more precise, the better. If a client later asks for something that isn’t on this list, you have a clear basis for a change order.

File Formats and Delivery Method

Specify what you’re handing over and how. Design files in Figma? Source files in Illustrator? Video in H.264 MP4? Audio in WAV and MP3? Put it in the contract.

A common source of friction: clients who expect source files when the contract only specified final deliverables. If you’re keeping source files as part of your licensing arrangement, say so. If you’re delivering them, specify exactly what that includes.

Number of Revision Rounds

This is non-negotiable. Define it.

“Two rounds of revisions” means two rounds. The contract should explain what a revision round consists of — typically one consolidated set of client feedback followed by your revisions.

Be specific about what’s considered a new round vs. a minor correction. A typo fix isn’t a revision round. A complete change of color palette is.

What to Explicitly Exclude

Counterintuitively, what you leave out of scope is just as important as what you include.

An exclusion list prevents the slow drift of scope creep. Some examples:

• “This contract does not include content writing, stock photography, or SEO optimization unless separately contracted.”
• “Backend development and CMS customization are not included in this scope.”
• “Print-ready files are not included; this contract covers digital delivery only.”

Exclusions shouldn’t feel hostile. Frame them as clarity, not confrontation. “To make sure we’re aligned, here’s what’s outside this project’s scope. Happy to quote on any of these separately.”

Including Milestones and Approval Points

For larger projects, break the work into milestones — and build in client approval at each one.

This does two things. First, it prevents a client from accepting all your work at the end and then claiming it wasn’t what they wanted all along. Second, it structures your payment schedule around real progress points.

For example:

• Milestone 1: Wireframes and site architecture — 25% payment due upon approval
• Milestone 2: Design mockups (home + inner pages) — 25% payment due upon approval
• Milestone 3: Development complete, staging site live — 25% payment due upon review
• Milestone 4: Final site live — 25% payment due

Each milestone should specify what “approval” means. Silence for five business days after delivery can count as implied approval — include language like: “If no feedback is received within five business days of delivery, this milestone is considered approved.”

PayOdin’s proposal-to-payment model aligns well with milestone-based work. Each payment has a human review step before it reaches the client, keeping the process transparent and documented throughout.

How to Handle Change Orders

A change order is a written amendment to the original scope. It’s how you handle client requests that fall outside what was agreed.

Your contract should reference the change order process explicitly. Something like: “Any additions or changes to the project scope will be documented in a change order and require written agreement before work begins. Change orders will be billed at [your hourly rate] or as a fixed additional fee.”

When a client asks for something outside scope, don’t say yes or no immediately. Say: “Happy to do that — let me put together a change order so we’re on the same page before I start.” Then deliver a brief written document specifying what the addition is, what it costs, and by when it’ll be done.

This protects you. It also protects the client from billing surprises.

Priya, a brand designer from India, started using change orders after a bad experience where a small client request turned into three weeks of unpaid work. “Now I just send a quick change order for anything outside the original brief. Clients always say yes because it’s clear and fair. I’ve never lost a client over it.”

Ownership and Intellectual Property

Your deliverables section should connect to your IP clause. Clients often assume they own everything you create for them immediately. That’s not always true or appropriate.

A common model: you retain IP ownership until final payment is received in full. Once paid, full IP transfers to the client. This is a legitimate and widely used approach that protects you from clients who receive work and then slow-walk payment.

Another model: you license usage rights but retain copyright. This is more common in photography, illustration, and stock-style work.

Whatever your model, it should be explicit in the contract — and your deliverables section should reference it.

Templates vs. Custom Contracts

Most freelancers start with a template. That’s fine. Free templates exist from resources like the Freelancers Union and AIGA. These give you solid bones.

But templates need to be customized per project. Copy-pasting the same deliverables section from one project to another is where the trouble starts. Every project has a different scope, different assumptions, and different risks.

Spend 15 minutes customizing the deliverables section for each new project. It’s the highest-ROI thing you can do before a project starts.

The Right Tone for Contracts

Contracts can feel adversarial. They don’t have to.

When you send a contract to a new client, frame it positively: “I want to make sure we’re both totally clear on what we’re building together — here’s the agreement that outlines everything we discussed.”

Most professional clients appreciate this. It signals that you’re serious and organized. A client who responds to your contract with suspicion or resistance is showing you something about how they operate.

The contract isn’t just a legal document. It’s also a filter. Clients who respect the process tend to be easier to work with throughout.

Conclusion

A great deliverables section is specific, concrete, and complete. It names exactly what’s included and explicitly notes what isn’t. It references revisions, file formats, approval points, and change orders.

Done well, it prevents 90% of the disputes that make freelancing stressful.

Pair your contract with clean invoice and payment processes and you’re running a professional freelance operation. PayOdin covers the payment side — a real person reviews every invoice before your client sees it, and there’s no company required to get paid. Learn more at payodin.com/for-freelancers.