Freelance Web Development Contract: 10 Clauses to Include

It’s 9 PM and a message pops up from your client. They want the database restructured, and they’re pretty sure it’s “just a minor tweak” that the original agreement already covers. You’ve sunk two weeks into refactoring you never billed for, and when you go back to check, nothing you signed actually says where the project ends.

Most developers have had some version of this conversation. A clear freelance contract for a web development project won’t stop clients from asking for things, but it changes how the conversation goes. Instead of arguing over what someone “thought was included”, you both open the document and check.

Below are the 10 clauses we think matter most for freelance developers, each with sample wording you can copy and adjust. They cover scope, sign-off, payments, who owns the code, cancellations, maintenance and liability.

A quick note: this is general guidance, not legal advice. Contract law differs from country to country (and state to state), so it’s worth paying a lawyer to look over your template once before you start reusing it.

1. Scope of work: treat the contract like a spec

You wouldn’t hand another developer a vague spec and hope for the best, so don’t do it to your client either. The scope is where they find out exactly what they’re paying for. Be as specific as you’d be in a technical doc.

Spell out the things clients tend to assume but almost never say:

• Pages, templates and features, by name
• CMS or framework (WordPress, Next.js, Shopify, etc.)
• Third-party integrations and APIs (payment gateway, CRM, email tool)
• Supported browsers and devices, and the oldest versions you’ll test on
• Who supplies content, images and copy, and by when
• What is not included (copywriting, SEO, logo design, ongoing hosting)

Don’t skip that last one. The “not included” list ends up being the line you point to most often, because it gives you a calm, simple answer when a request shows up that nobody ever discussed.

Sample wording: “The Developer will deliver the features listed in Schedule A. Any feature, integration or design change not listed in Schedule A is outside the scope of this Agreement and will be handled under the Change Order clause.”

If the site will handle personal data (logins, customer records, payments), be clear about who’s responsible for privacy compliance. Under laws like GDPR, a client may ask you to sign a Data Processing Agreement. Work out up front whether that’s part of your job on this project.

2. Acceptance criteria: define “done”

Scope covers what you’ll build. Acceptance covers how you both agree it’s finished. Leave it out and “done” quietly turns into “whenever the client stops asking for changes”, which could be never.

You need to pin down three things:

1. What gets tested: the features in your scope, checked against the agreed browsers and devices.
2. The review window: for example, 7 business days after you deliver a milestone for the client to test (user acceptance testing, or UAT).
3. What happens when the window closes: if the client hasn’t reported a defect in writing, the milestone counts as accepted.

Sample wording: “The Client will review each deliverable within 7 business days and report any defects in writing. Deliverables with no reported defects at the end of that period are deemed accepted.”

That “deemed acceptance” line matters more than it looks. Without it, a project can sit for weeks while you chase feedback, and your next milestone payment sits with it.

3. Change orders: price every “one more thing”

Scope creep almost never shows up as one big request. It’s ten small ones, each too minor to argue about on its own. A change-order clause gives every one of them a price, so it becomes a quick decision instead of a favour you quietly absorb.

The process doesn’t need to be complicated:

1. The client asks for something outside the scope.
2. You reply with a short change order: what it is, the cost, and the effect on the timeline.
3. Work starts only after the client approves it in writing.

It also helps to define the difference between a bug and a feature request, because clients often blur the two:

• Bug: the code doesn’t do what the agreed scope says it should. You fix it as part of the project or warranty.
• Feature request: anything the agreed scope doesn’t describe. It goes through a change order.

Sample wording: “Requests outside Schedule A require a written Change Order stating the added cost and revised timeline. Change work is billed at [your hourly rate], or as quoted, and begins only after written approval.”

Worried about coming across as difficult? We’ve written more on wording this without souring the relationship: How to Use a Freelance Design Contract Scope Creep Clause.

4. Milestone payments instead of 50/50

Half upfront, half at launch sounds fair on paper. On a three-month build, though, it means you do most of the work before you see the second payment. And that final 50% easily becomes a bargaining chip: “we’ll pay once you just add this one thing.”

Tying payments to milestones works better:

Milestone	What the client gets	Typical share
Kickoff / discovery	Signed scope, sitemap, wireframes	25–30% (paid upfront)
Core build	Working back end and key features on staging	25–30%
Front end + content	Near-final site on staging for review	20–25%
Launch	Site live and accepted	20–25%

Treat these percentages as a starting point and adjust them for the size and risk of the project.

Then add one rule that protects all of it: the next phase doesn’t start until the last invoice is paid. That way, the most unpaid work you can ever be owed is a single phase.

Sample wording: “Invoices are due within 7 days. The Developer may pause work on any milestone while a previous invoice remains unpaid, and the delivery timeline will be extended by the length of the pause.”

5. Late payment terms

A payment schedule with no consequences is really just a suggestion. Give a due date (7 or 14 days is common) and say what happens when it passes: a reminder first, then a late fee, then a pause on work.

Sample wording: “Payments more than 14 days overdue incur a late fee of [1.5]% per month on the outstanding amount, where permitted by law.”

You might never actually charge the fee, and that’s fine. Just having it in writing tends to move your invoice up the client’s to-do list.

6. Code ownership transfers on final payment

A lot of contract templates say the client owns everything “upon creation”. That’s a bad deal for you. If the client already owns the code and has access to the repo and server, there’s not much you can do when the final invoice goes unpaid.

A safer approach is to tie the transfer of ownership to payment:

• During the project, the client gets a licence to review and test the work.
• Full ownership (or an assignment of copyright) passes to the client only once all fees are paid.
• Until then, keep the code in a repository and staging environment you control. Hand over the repo, admin access and production deployment after the final payment clears.

Sample wording: “Upon receipt of full payment, the Developer assigns to the Client all rights in the custom code created under this Agreement. Until then, the Client receives a non-exclusive licence to use the deliverables for review and testing only.”

This puts you in a much stronger spot if there’s ever a dispute. It won’t stop a determined client from misusing the work, though, so pair it with milestone billing.

7. Pre-existing code and open-source components

Most developers carry their own snippets, starter themes and utility libraries from one project to the next. Make sure you keep the rights to them. A broad “client owns everything” clause could, at least on paper, hand over code you’ll need for your next job.

• Your pre-existing tools: you keep ownership and give the client a permanent licence to use them as part of their site.
• Open-source and third-party code (frameworks, plugins, packages): these stay under their own licences. You can’t transfer ownership of them, so say so.
• Paid licences (premium plugins, fonts, stock images): state who buys them and whose name they’re registered in.

Sample wording: “The Developer retains ownership of pre-existing tools and code, and grants the Client a perpetual, non-exclusive licence to use them within the delivered project. Third-party and open-source components remain subject to their respective licences.”

8. Cancellation and kill fee

Projects get cancelled, and usually it’s nothing personal. Budgets get cut, companies pivot, someone new takes over. Your contract should make sure you’re paid for the work you’ve done and for the time you held for this client instead of taking on other work.

• The client pays for all completed milestones plus work in progress up to the cancellation date.
• A kill fee (often 10–25% of the remaining project value) covers the booked time you can’t easily refill.
• Code and files for completed work are handed over only once those amounts are paid.

Sample wording: “Either party may terminate this Agreement with 14 days’ written notice. On termination by the Client, the Client will pay for all work completed to date plus a cancellation fee of [15]% of the remaining unpaid project value.”

9. Warranty, maintenance and hosting

Many clients assume the build price comes with support forever. It’s kinder to everyone to say clearly where it stops.

• Warranty period: for example, 30 days after launch. During it, you fix bugs (as defined in your scope) at no extra cost.
• After the warranty: updates, new features, plugin and CMS upgrades, and security patches fall under a separate monthly maintenance plan or are billed hourly.
• Third-party changes: you’re not responsible for breakage caused by later updates to browsers, plugins, APIs or hosting, or by changes the client or another developer makes, unless a maintenance plan covers it.
• Hosting and credentials: say who owns the hosting, domain and third-party accounts. Ideally the client owns them all in their own name and gives you access, so nothing is stuck under your login.

Sample wording: “The Developer will fix defects reported within 30 days of launch at no charge. Work after this period, including updates required by third-party software changes, is provided under a separate maintenance agreement.”

If the site handles sensitive data, link to your security and compliance standards so it’s clear where your responsibility ends.

10. Limitation of liability

Say a checkout bug costs your client a full day of sales. Could they come after you for that money? Without a cap, they might. A limitation-of-liability clause sets a ceiling (usually the total fees paid under the contract) and rules out indirect losses like lost profits.

Sample wording: “The Developer’s total liability under this Agreement is limited to the fees paid by the Client. Neither party is liable for indirect or consequential losses, including lost profits or data.”

For bigger projects, it’s also worth looking into professional indemnity insurance.

Keep the contract where the work happens

Even a great contract doesn’t help much if nobody can find it. When the signed PDF is buried in an email thread from four months ago, it’s easy for a client to say “I never agreed to that.”

It’s much easier when the proposal, signed contract, change orders and invoices all live in one place. With Kwill, you can send a proposal, send contracts for signature, and invoice each milestone from the same workspace. That way every approval and payment leaves a clear record you can point back to. If you’re comparing tools, our roundup of the best client portal software for freelancers covers what to look for.

Freelance web development contract checklist

Before your next contract goes out, run through this list and make sure it covers:

• Scope: features, integrations, browsers and an “out of scope” list
• Acceptance criteria and a review window with deemed acceptance
• A change-order process with your rate for extra work
• Milestone payments, with work pausing on unpaid invoices
• Due dates and a late fee
• Code ownership transferring on final payment
• Rights to your pre-existing code, and open-source licences
• Termination terms and a kill fee
• Warranty period, maintenance terms and hosting/account ownership
• A cap on your liability

Frequently asked questions

Who owns the source code in a freelance web development project?

It comes down to what the contract says. In many countries, including the US, UK and India, a freelancer owns the copyright in code they write unless the contract assigns it to the client. Make that assignment conditional on final payment, and keep the rights to your pre-existing tools.

What happens if a client cancels a web development project halfway through?

If your contract has a termination clause, the client pays for completed milestones, work in progress and any agreed kill fee. Without one, you may end up negotiating, or even going to court, just to get paid for work you’ve already done.

How should I handle bug fixes after launch?

Offer a fixed warranty period, such as 30 days, for defects against the agreed scope. After that, move the client onto a maintenance plan or hourly billing for fixes, updates and new features.

Is an email agreement legally binding for a web development project?

Often, yes. In many places an email exchange can form a valid contract. The trouble starts when you need to prove which terms you agreed to and they’re scattered across a dozen messages. One signed document is much easier to rely on.

Start your next project protected

You don’t need a 30-page agreement. You need these 10 clauses, written in plain language, reused on every project and kept somewhere you and your client can both find them.

Try Kwill to send proposals, get contracts signed and collect milestone payments in one place.