A web development contract should name the exact deliverables, two to three revision rounds, payment milestones, a written acceptance test with a deadline, and who owns what after final payment. And here is the part most templates skip: under US law, a contractor-built site is generally not work-made-for-hire, so ownership needs a signed assignment plus day-one control of the domain, repo, and licences.
Most guides hand you a blank download and wish you luck. I think that is backwards. A blank form cannot tell you what done looks like, what happens when the client goes quiet, or what to do when the redesign you just shipped eats the site's rankings. So this post gives you a filled-in annotated template first, then notes on each part, then two fixes the top results mostly miss.
This is not legal advice. It is a working template plus the clauses I would flag before signing, and you should have a lawyer review your final contract.
What should I include in a web development contract before work starts?
A web development contract needs eight parts before work starts: defined scope with exclusions, milestones with prices, a revision rule, an acceptance test with a deadline, payment terms with pause rights, ownership transfer on final payment, a warranty window, and termination plus handover. Each part needs names, dates, and a test, not adjectives.
The common advice is a ten-clause list. Scope, payment, revisions, IP, warranty, termination: tick the boxes and you are safe. That list is right about the boxes and wrong about what makes them hold. A survey of 213 projects found contracts with detailed scope plus a revision limit had far less creep than handshake deals (ContractPilot survey of 47 freelancers and 213 projects).
| Clause | What it must say | Why it matters |
|---|---|---|
| Scope and exclusions | Pages, features, stack, integrations, content duties, plus what is not included | Stops free work disguised as small tweaks |
| Milestones and price | Dated milestones, amount each, due date, pause right | Turns progress into payable invoices |
| Revisions | Rounds included, who approves, what counts as one round, hourly rate after | Caps the most common leak |
| Acceptance | Testable criteria, review window, defect report format, silence rule | Makes delivery end on a date |
| Payment | Deposit, milestones, net terms, late charge, stop-work right | Funds the build as it moves |
| Ownership | Assignment trigger, pre-existing tools, third-party licences, accounts | Hands over a site you can actually run |
| Warranty | Length, what is covered, what is excluded | Separates bugs from new work |
| Termination and handover | Notice, payment for work done, kill fee, files and credentials | Closes dead projects cleanly |
Now the filled example. Picture a small agency signing a five-page marketing site for a local bakery:
| Block | Filled example |
|---|---|
| Parties and date | Dev and bakery owner, start date, named approver on client side |
| Scope | Five pages on WordPress: home, menu, gallery, contact, enquiry form, tap-to-call on mobile |
| Exclusions | No logo redesign, no copywriting beyond light edits, no online ordering or payments |
| Milestones | Mockups, staged build, launch, each with a date and a fixed amount |
| Revisions | Two rounds, one consolidated list from the named approver per round, extra rounds at an hourly rate |
| Acceptance | Staging link, written Delivery Notice, review window, defect list tied to scope |
| Payment | Deposit before start, balance split across milestones, short net terms, pause if overdue |
| Ownership | Assignment on final payment, theme code licensed back, third-party list attached |
| Warranty | Short fix window for non-conformance to scope only, client edits and hosting excluded |
| Handover | Repo access, logins, domain and renewal list after final payment |
One note that carries weight: the exclusions list is the highest-leverage paragraph in the file.
If you write proposals too, keep the two documents aligned: your proposal promises the outcome and your contract defines the edges, like the structure in this website design proposal template.
When is a free website development template enough?
A free website development template is enough for a small standard build with a client you trust, when you fill every blank, add dates and names, and get a one-time lawyer review before you reuse it. It is not enough for big budgets, regulated work, cross-border deals, or tangled ownership with subcontractors.
Most freelancers start from a download. Only about four in ten use a written contract on every engagement, which leaves most deals running on messages and memory (Damongo guide to freelance client agreements).
And the old Freelancers Union numbers still explain why that stings: in that survey only about a quarter always used contracts, most had trouble getting paid at some point, and the average unpaid amount ran into the thousands (Freelancers Union nonpayment survey of over 5,000 workers).
So use this rule. Free template plus your careful fill plus one lawyer review: fine for a standard brochure site with no weird IP. Lawyer-drafted or heavily reviewed: big budgets, regulated work, cross-border clients, or deals with subcontractors. The review fee amortises fast because you reuse the base.
Red flags that push you to a lawyer now: the client sends their own paper, they strike your acceptance or ownership section, they refuse a deposit, or they want source files before paying. A template cannot fix a client who will not sign one.
How do I handle redesign work differently from new builds in a contract?
Treat a redesign as a migration with inherited risk, not a fresh build with a page count. Add five paid milestones: a pre-migration baseline, a URL decision with analytics access, a one-to-one redirect map approved before building, parity checks on titles and technical setup, and a post-launch recovery review with a free-fix trigger.
New builds create from zero. Redesigns inherit indexed pages, ranking keywords, backlinks, and whatever the old CMS did quietly for years. Three failure modes show up again and again: missing redirects, thinner replacement content, and changed URLs nobody mapped (SearchPod SEO-safe redesign RFP pack).
And the vague line is the trap. A checklist of redesign clauses warns that SEO included means nothing until it names redirects, metadata, headings, schema, URL planning, sitemap, Search Console, and a post-launch crawl, citing Google's own guidance to use redirects when URLs change (YourWebTeam website contract checklist).
So write the redesign addendum as work, not wishes:
| Milestone | Deliverable | Paid when |
|---|---|---|
| Baseline | Crawl of indexed pages plus top-keyword rankings, signed off before teardown | On sign-off |
| Access and URL decision | Search Console access in week one, written keep-versus-change URL decision | On decision |
| Redirect map | One-to-one map of old to closest new address, single hop, tested on staging | On approval before build |
| Parity and launch checks | Titles, headings, schema, sitemap, robots, live crawl and SSL check | At launch |
| Recovery review | Post-launch monitoring window with a threshold and a free-fix duty | At review close |
Two honest limits. Small transient fluctuation after a move is normal, but a large or persistent drop usually means a redirect or content fault. And if the old site has near-zero organic clicks and no links, document that finding and skip the deep migration scope.
Before you scope the addendum, run a quick audit of what the old site actually has. I use the same lens as a site audit that checks status, platform age, and HTTPS, because the audit output becomes the baseline exhibit.
If you sell redesigns, find outdated sites first. LeadsAgent does that part: you describe the customer once, it finds matching local businesses on live Google Maps, checks each homepage for outdated signs and conversion gaps, and hands you one ranked list to pitch.
See businesses that need a redesign: describe your ideal rebuild customer once and get a ranked list of local businesses with outdated sites to scope this week.
How should acceptance and revisions be defined so delivery ends cleanly?
Define acceptance as a test with a clock. Put testable criteria in the scope before coding, send a written Delivery Notice, give a defined review window, require written rejections that cite the scope with steps to reproduce, and state what silence and live use mean. Move small issues to a punch list so minors cannot block the invoice.
Most templates say the client approves the work when satisfied. That word is the leak. Satisfaction has no test, no deadline, and no format, so the project drifts while the final invoice waits. Legal analysis attributes a large share of vendor revenue fights to acceptance mechanics (Story LLP acceptance framework).
But the sharper version matters for cash: a late charge cannot accrue on an invoice that is not yet due. What makes the invoice due is acceptance, which is why the acceptance section is really a payment section wearing different clothes.
Use this shape. Criteria signed before code, with checks the client can run. Delivery Notice by email to the named approver, starting the window. A review window you both sign, matched to testability. Written rejection only: scope section, steps to reproduce, expected versus actual. Severity split: blocking defects pause that milestone, minor items go to a short punch list without holding payment. Silence and use rule: no written rejection in the window, or putting the work live, counts as accepted.
Two caveats keep this honest. The fixed numbers are negotiated norms, not proven optima, with longer windows closer to market standard for complex builds. And get local advice outside familiar business deals, since silence-means-acceptance is weak or void in some places.
Revisions ride on the same rail. Two rounds is the norm, but the number only works with the definition: one round equals one consolidated list from the named approver, and anything outside scope needs a signed change note before work. Dormancy needs its own sentence too, since one template suspends after twenty straight business days of silence plus a restart charge (Gatilab web development contract PDF).
After launch, the warranty line should separate bugs from new work: a short window for non-conformance to scope, with client edits, hosting, and third-party updates excluded. That boundary is also where care plans live, which is why I scope fixes next to a web maintenance plan.
Who owns the code, design and content after launch?
Ownership transfers when a signed present-tense assignment says so, on a defined trigger like receipt of final payment in full, for defined deliverables including source, design files, and artwork. Until then the client holds at most a licence to use what was delivered. The domain, repo, hosting, and third-party licences each need their own line, because copyright and control are different jobs.
The common advice says one sentence does it: client owns everything on final payment, maybe labelled work-made-for-hire. Most ranking templates say exactly that. And for US contractor builds it is the sentence I trust least in the file.
But the statute draws a narrower box. Copyright starts with the author, and an employer owns automatically only for true employment work, while transfers need a signed writing from the owner (17 USC Sections 201 and 204).
Commissioned work-made-for-hire needs two things at once: a signed agreement saying so plus work that fits one of nine listed categories, and generic website code and design are not on that list (Copyright Office Circular 30).
So the mechanism is simple. Your contractor starts as the author even after being paid. Without a valid assignment the client may hold only an implied licence: enough to stay online, not enough to hand the code to a new developer or register the mark. Add a domain in someone else's name and a repo in your personal account, and you have handed over a folder the client cannot run.
The evidence beyond the statute points the same way. A launch-ownership guide walks through the category failure and the domain registrant change that triggers a two-month transfer lock under registrar policy (Zenesa guide to who owns a website after launch).
Practitioner analysis adds the fix: keep a work-made-for-hire line if you like, but add a present-tense hereby-assigns assignment, carve out pre-existing tools, list third-party items, and get cooperation plus a chain from subcontractors (Spengler analysis of contractor code ownership).
What to do instead, in four artifacts:
| Artifact | Owner from day one | Transfer line |
|---|---|---|
| Copyright in deliverables | Contractor until paid | Hereby assigns all right, title, and interest including copyright in defined deliverables on final payment, with rights to modify |
| Domain and registrar | Client name and client email, dev gets DNS only | Change-of-registrant duty plus renewal list, planned around the transfer lock |
| Repo, hosting, CMS, analytics | Client organisation with dev as a user from the first commit | Access inventory with each release, handover within days |
| Licences and bought assets | Named holder, cost, and renewal per item | Inventory attached to each milestone, client pays at cost |
When is the common advice still right? When the build is truly employment work, or when the deliverable genuinely fits a listed category plus a signed agreement. For the usual freelance website, assume it does not fit and write the assignment.
Subcontractors break chains quietly: you cannot assign what your freelancer never assigned to you. If you outsource builds, warranty that chain in writing, which is one reason I check delivery promises against a white label website development checklist.
FAQ
Do I need a lawyer if I already have a template?
For a small standard build, a filled template plus a one-time review is usually the practical path. For large budgets, regulated industries, or subcontracted IP, have the final draft reviewed before anyone signs.
Does paying in full automatically give the client the copyright?
Not under US law for the usual contractor website. Payment alone does not transfer copyright without a signed assignment, and the work-made-for-hire label alone generally does not cover generic code and design. You need the hereby-assigns sentence plus the domain, repo, and licence lines, reviewed for your jurisdiction.
How long should the acceptance window be?
Match it to testability: a few business days for a small brochure site, longer for stores and integrations. Name the window, the notice that starts it, the rejection format, and what silence and live use mean.
If your next build is still missing, start from demand you can scope cleanly. I find pitches go better when the prospect already shows the problem, which is why I pair every contract with prospecting like the playbook in how to get web design leads.
Get your next scoped project: tell LeadsAgent who you build for and get a ranked list of local businesses with the website evidence attached, so your next contract starts from a real baseline.
