A web development contract is the written agreement that sets scope, payment, and code ownership between a developer and a client before any work starts — distinct from a design contract because it also has to cover who owns the source code, what third-party or open-source components end up inside it, and how bugs get fixed once the build is live. Download the ready-to-fill template below, or read the field-by-field checklist first.
A complete, ready-to-fill PDF — 18 clauses, blanks for every detail, and a signature block for both parties. Free, no email, no account. Read it and adapt it before you use it; the cover page explains what it can and cannot do for you.
Need the other party to sign it too? Send it for signature with a full audit trail and a tamper-evident seal on the finished file — they never need an account. See pricing.
This document is a general-purpose template provided for information only. It is not legal advice, it does not create a lawyer–client relationship, and nobody has reviewed it against your situation.
Laws differ by country, state and province, and they change. A clause that is standard in one place can be unenforceable — or illegal — in another. Terms that are ordinary between two businesses can be void in a consumer or employment context.
Read every clause before you use it, fill in every blank, and delete anything that does not apply. For anything high-value, unusual, or that you could not afford to lose a dispute over, have a qualified lawyer in your jurisdiction review it before it is signed.
These are the fields and clauses a web development contract needs. Leaving one out doesn’t necessarily void the contract, but each gap is a spot where you and your client can end up disagreeing about what you actually agreed to — and for code and licensing, disagreeing after launch is expensive to unwind.
Client & developer names. Full legal names (or registered business names) for both sides, plus the business entity if either party is incorporated. This is who the contract actually binds.
Project scope, features & deliverables. List exactly what’s being built — the features, the stack, the integrations, the environments (dev, staging, production) — and what’s explicitly excluded. A vague scope (“a web app”) is the single biggest source of development disputes.
Timeline & milestones. A start date, key milestones (spec approval, environment setup, feature-complete build, testing, launch), and a target completion date. Tie each milestone to a deliverable the client must approve before work continues.
Payment schedule & rate. The total fee or hourly rate, and how it’s split — a common structure is a deposit up front, a payment on acceptance testing sign-off, and a final payment on launch. State the currency, due dates, and what happens if a payment is late.
Testing, bugs & revisions policy. How many rounds of revisions are included, what counts as a bug versus a new feature, and the rate charged for work beyond that. Without a written definition, “that’s not working right” can mean very different things to a client and a developer.
Code ownership transfer on final payment. State clearly that the source code — not just the visual output — transfers to the client only once final payment clears, and that the developer’s own pre-existing tools and frameworks stay the developer’s, licensed for use in the delivered project.
Third-party & open-source licensing disclosure. A list of every third-party or open-source component used, and its licence. This protects the client from unknowingly inheriting a copyleft obligation, and protects the developer by making the disclosure — and any client-directed exception — explicit and in writing.
Post-launch maintenance & bug-fix window. A fixed period after launch during which the developer fixes defects against the agreed specification at no extra charge, with response times and a clear line between a free bug fix and chargeable new work.
Kill-fee / termination clause. What happens if either side ends the project early — notice period, and a kill fee covering work already completed. This protects the developer from a client who cancels mid-project after most of the work is done.
Signatures & date. Both the client and the developer sign and date the contract. An unsigned contract is just a proposal — it isn’t binding until both parties have signed it.
Fill in the template above and send it to your client for signature with a free Evenseal account — 3 documents a month, no card required. Only need your own copy signed? Self-sign for free with no account at /sign-pdf.
Not legal advice — for large projects, unusual licensing terms, or high-value IP, have a local attorney review your contract.