A freelance web developer contract isn’t paperwork for the sake of it. It’s the document both sides reach for when memories differ about what was promised, when an invoice is late or when the project changes direction. This guide walks through the clauses I consider essential, what each one should say, and sample wording you can adapt.
Important: this is practical guidance from a developer’s perspective, not legal advice. Laws differ between countries and states. Have a qualified lawyer in your jurisdiction review your template before you rely on it.
Why every freelance web developer contract matters, even for small jobs
Small projects feel too informal for a contract, but they’re where misunderstandings are most common: a “quick landing page” with no written scope can absorb weeks. A contract doesn’t signal distrust. It shows the client you run a professional business, and it forces both of you to agree on the details before money and time are spent.
You don’t need a fifty-page document. A clear agreement of a few pages, plus a separate statement of work (SOW) per project, covers most freelance engagements. The master agreement holds the terms that rarely change (payment, IP, liability), while each SOW defines what you’re building this time.
Scope of work and deliverables
Scope is the clause that prevents most disputes, so it deserves the most precision. Describe what you’ll deliver in terms a non-technical client can check:
- The pages, templates, features and integrations included, listed individually.
- What the client must provide (content, images, brand assets, API access) and by when.
- Browsers, devices and accessibility level the work is tested against.
- The number of revision rounds included at each stage.
- An explicit out of scope list: copywriting, SEO content, hosting costs, third-party licences, ongoing maintenance.
Sample wording: “The Developer will deliver the items listed in Schedule A (the ‘Deliverables’). Any work not listed in Schedule A is outside the scope of this Agreement and will be handled under the Change Request process in Section 6.”
Define what “done” means too. An acceptance clause gives the client a set period to review each deliverable and report defects against the agreed scope; if they don’t respond in that period, the deliverable is treated as accepted. Without it, projects can sit at “almost finished” indefinitely.
Payment schedule and late fees
Tie payments to milestones the client can see, and take an upfront deposit before work starts. A common structure is a deposit, one or more milestone payments and a final payment at launch, but choose what suits the project’s size and your cash flow. My guide on how to price freelance web development projects covers fixed-price versus hourly in more detail.
The payment clause should state:
- Amounts or percentages, and the milestone that triggers each invoice.
- Payment terms, such as due within a stated number of days of the invoice.
- Currency, accepted payment methods, and who bears transfer fees and taxes.
- What happens when payment is late: a late fee or interest (where local law allows it) and your right to pause work.
Sample wording: “If any invoice remains unpaid [X] days after its due date, the Developer may suspend work until payment is received, and project timelines will be extended by the length of the suspension. Overdue amounts accrue a late fee of [X]% per month, or the maximum permitted by law, whichever is lower.”
The suspension right is often more useful than the late fee. It means you never end up funding a client’s project with your own unpaid time.
Change requests
Projects change; that’s normal. The contract should define how changes are handled so they’re priced and scheduled rather than absorbed silently.
- The client submits a change request in writing.
- You respond with the effect on cost and timeline.
- Work on the change starts only after the client approves the estimate in writing (email is usually fine if the contract says so).
The process itself, with templates, is covered in my guide on how to handle scope creep. The contract’s job is to make that process binding.
Intellectual property transfer on final payment
Clients usually expect to own the website. Developers need to get paid. The standard compromise is that ownership of the custom work transfers to the client once all fees are paid in full. Until then, the client gets a licence to use the work in progress, and you keep the right to withhold it.
Three distinctions belong in this clause:
- Custom deliverables: the code and designs made specifically for the client, which transfer on final payment.
- Pre-existing materials: your own libraries, starter themes, snippets and tools. You keep ownership and grant the client a perpetual, non-exclusive licence to use them as part of the project. Otherwise you could accidentally sign away code you reuse on every job.
- Third-party materials: open-source packages, premium plugins, fonts and stock images, which remain under their own licences. Note who pays for and holds commercial licences.
It’s also reasonable to keep the right to show the project in your portfolio, unless the client needs confidentiality.
Warranties and the bug-fix window
A warranty clause defines what you’ll fix for free after launch and for how long. Pick a specific window and say that bugs, meaning the deliverables not working as described in the scope, will be fixed at no cost during it.
Equally important is what the warranty excludes:
- Changes made by the client or other developers.
- Problems caused by plugin, theme, CMS, browser or server updates after launch.
- Hosting outages and third-party service failures.
- New features or design changes, which are change requests.
After the window closes, ongoing support moves to an hourly rate or a maintenance agreement. Offering a retainer at handover is good for both sides; see website maintenance retainer plans for how I’d structure one. Avoid broad promises such as “the site will be secure” or “bug-free”. Nobody can honestly guarantee those.
Confidentiality
You’ll see business plans, customer data, credentials and unreleased products. A mutual confidentiality clause commits both sides to keep the other’s confidential information private and to use it only for the project. Include the usual exceptions: information that’s already public, independently developed, or that must be disclosed by law.
If the project involves personal data, the client may also need a data processing agreement under laws such as the GDPR or India’s DPDP Act. That’s a separate document; flag it rather than improvising one inside your contract.
Hosting, accounts and credentials
This clause is often missing, and it causes real problems at handover. Spell out:
- Domain, hosting, email and third-party accounts are registered in the client’s name and paid by the client, with you added as a user.
- How credentials are shared (a password manager, not email) and that the client should rotate them after the project ends.
- Who is responsible for backups and server security after launch.
- That you aren’t responsible for failures of hosting or services you don’t control.
Registering a client’s domain in your own account feels helpful at the time, but it makes you a gatekeeper and can create friction if the relationship ends.
Termination, liability cap and governing law
Termination
Either party should be able to end the agreement with written notice. The clause must say what happens next: the client pays for work completed up to that date (and any non-refundable costs), the deposit is non-refundable or partly refundable as agreed, and you hand over the completed work once paid. Include immediate termination for a material breach that isn’t fixed within a set period after notice.
Limitation of liability
Without a cap, a bug that takes a store offline during a sale could expose you to a claim far larger than your fee. A liability cap typically limits your total liability to the amount the client paid under the contract, and excludes indirect losses such as lost profits or lost data. Whether and how such caps are enforceable depends on local law, which is one of the main reasons to have a lawyer review your template. Consider professional indemnity insurance as well.
Governing law and disputes
State which country’s or state’s law governs the contract and where disputes are resolved. When the client is abroad, this matters a lot: you don’t want to discover you’d have to go to court in another country. Many freelancers add a step requiring good-faith negotiation, then mediation or arbitration, before litigation.
Key takeaways
- Use a master agreement plus a statement of work per project, with an explicit out-of-scope list.
- Tie payments to milestones, take a deposit, and include the right to pause work for late payment.
- Transfer IP on final payment while keeping ownership of your reusable tools.
- Define a bug-fix window and what it excludes, then offer maintenance separately.
- Keep accounts and domains in the client’s name, and cap your liability.
- Get your template reviewed by a lawyer in your jurisdiction.
Frequently asked questions
Do I need a contract for a small freelance web project?
Yes. A short agreement with a clear scope, payment terms and IP clause protects both sides and takes little time once you have a template.
When should intellectual property transfer to the client?
A common approach is that ownership of custom work transfers when all fees are paid in full, while you keep ownership of pre-existing tools and code and license them to the client.
How long should a bug-fix warranty last?
There is no standard length; choose a fixed window that fits the project’s size and state it clearly. Exclude problems caused by later updates, third parties or changes made by others.
Can I use a free online contract template?
A template is a reasonable starting point, but adapt it to how you work and have a lawyer in your jurisdiction review it. Templates written for another country may not be enforceable where you or your client are based.
Looking for a developer who works with clear contracts and transparent scopes from day one? Get in touch and tell me about your project.
