You’re about to hand someone a deposit, your brand assets, and the keys to your future website. The contract they slide across the table is supposed to protect both of you. Most of the time, it protects them.
This guide flips that. It’s written for the business owner paying the invoice, not the developer collecting it. Every clause below exists because someone, somewhere, learned the hard way.
Key Takeaways
- A web developer contract should clearly define scope, payment milestones, ownership of code and design, timelines, revision limits, and what happens if things go wrong.
- The single biggest cause of project disputes isn’t bad work. It’s vague scope language that lets either side interpret deliverables differently.
- You should own the source code, design files, and content after final payment. If the contract doesn’t say so, you don’t.
- A kill fee, exit clause, and data handover protocol protect you if the developer disappears, ghosts, or underperforms.
- Watch for indemnity clauses, auto-renewals on hosting, and IP carve-outs that quietly let the developer reuse your custom work for someone else.
Have questions? We’d love to hear from you.
Quick Answer: What Should a Web Developer Contract Include?
A web developer contract should include eleven core sections: the parties and contact details, scope of work, project timeline and milestones, payment terms, revision policy, intellectual property ownership, confidentiality and data protection, third-party assets and licensing, warranties and liability limits, termination and kill fee, and dispute resolution. Each section should name specific deliverables, dates, and dollar amounts. Vague language is where money disappears.
Why Most Web Development Contracts Quietly Favor the Developer
Have questions? We’d love to hear from you.
Walk through a standard freelance or agency contract and you’ll spot a pattern. Scope is described in adjectives (“modern,” “responsive,” “user-friendly”) instead of nouns and numbers. Payment is front-loaded. Revisions are “reasonable.” Ownership transfers “upon final payment” without saying what that means if the developer ghosts you at 90%.
None of this is sinister. Developers write contracts that protect developers. Lawyers tweak them. Templates get copied. Nobody is sitting there asking, “Wait, what does the client actually need protected?”
That’s the gap this article fills.
Hiring a developer this quarter?
1. Parties, Contact Details, and Signing Authority
Sounds boring. Isn’t.
The contract should name the legal entity you’re hiring, not just a person’s brand. “Acme Web Studio LLC” is enforceable. “John Doe, freelance developer” is enforceable against John personally — fine if John has assets, useless if he doesn’t.
Three things to nail down here:
- The legal name and registered address of both parties
- Who has authority to sign and approve changes (one named person on each side avoids “but Sarah approved it” arguments)
- A clause requiring written notice for any change of contact, billing address, or signing authority
If the developer is a sole proprietor working under a brand name, ask for their personal name as the signatory. Brands fold. People are still reachable.
2. Scope of Work — Written in Nouns and Numbers, Not Adjectives
This is the clause that ends 80% of disputes before they start.
A weak scope reads: “Developer will design and build a modern, responsive WordPress website for Client with up to 10 pages.”
A strong scope reads: “Developer will deliver: (a) a WordPress 6.x website with a custom theme based on Figma mockups approved on [date]; (b) ten unique page templates: Home, About, Services (parent + 4 children), Blog index, Single post, Contact, and 404; (c) integration with HubSpot CRM via the official plugin; (d) WCAG 2.1 AA accessibility compliance verified by axe DevTools; (e) Lighthouse mobile performance score of 85 or higher on the homepage at launch.”
See the difference? The first invites argument. The second doesn’t.
Your scope section should answer:
- How many pages, page types, and page templates?
- Which CMS, framework, or platform — with the version?
- Which third-party integrations, and who pays for the licenses?
- What performance benchmarks must the site hit at launch?
- What’s explicitly out of scope? (List this. It’s the single most powerful protection you can write into the contract.)
If your developer pushes back on writing scope this precisely, that’s information. Build the contract anyway.
3. Timeline, Milestones, and Late Delivery Consequences
A timeline without consequences is a wish.
Break the project into milestones, each with a deliverable, a date, and a payment trigger. A typical site might run:
- Milestone 1: Discovery and approved sitemap (Week 1) — 20% payment
- Milestone 2: Approved design mockups (Week 3) — 20%
- Milestone 3: Functional staging build (Week 6) — 30%
- Milestone 4: Final launch on production (Week 8) — 20%
- Milestone 5: 30-day post-launch support complete — 10%
Then add the part most contracts skip: what happens when a milestone slips. A fair late-delivery clause might say: “If a milestone is delivered more than 10 business days late due to Developer’s delay (not Client delay or force majeure), Client may reduce that milestone’s payment by 5% per week of delay, capped at 20%.”
That’s not a punishment. It’s a price for unreliability that both parties agreed to upfront.
Curious how long projects actually take versus what gets quoted? Our breakdown of real website build timelines shows the gap between estimate and reality.
4. Payment Terms — Including the Stuff That’s Usually Buried
Payment should be tied to milestones, not calendar dates. If you pay on the 1st of each month regardless of progress, you’re funding delay.
Lock in:
- The total fixed price, or the hourly rate with a cap you cannot exceed without written approval
- The deposit (20–30% is normal; over 50% is a flag)
- The exact deliverable that unlocks each payment
- The currency, payment method, and who eats wire fees
- Late payment interest (yes, your developer can charge this — and you can negotiate the rate down)
- A change-order process: any new work outside scope requires a written estimate signed by both sides before work starts
That last one matters more than people realize. Without a change-order clause, “scope creep” becomes a he-said-she-said billing dispute at the worst possible moment.
5. Revision Policy with Real Numbers
“Reasonable revisions” is a trap.
Spell out:
- Number of revision rounds at each stage (e.g., “3 rounds on design mockups, 2 rounds on the staged build”)
- The window to submit revisions (e.g., “within 7 business days of deliverable presentation”)
- The hourly or per-round rate for revisions beyond the included number
- What qualifies as a “revision” versus a “new scope item” (changing button color = revision; adding a booking system = new scope)
Both sides win when this is clear. You stop fearing the revision invoice. The developer stops dreading endless tweak requests.
6. Intellectual Property and Code Ownership — Read This One Twice
This is where customer-protection contracts diverge sharply from developer-protection contracts.
A standard developer contract often says: “Upon final payment, Developer assigns to Client the intellectual property rights in the final deliverables.” Sounds good. Read it again.
Watch for these carve-outs:
- “Pre-existing IP” — code the developer wrote before your project, often including reusable libraries. They keep these. Fair, but the contract should name the libraries.
- “Tools and methodologies” — vague phrase that can be stretched to mean “anything we want to reuse on another client.”
- “Open-source components” — the developer can’t assign these to you because they don’t own them. Fine, as long as the license terms are listed.
- Design files — Figma, Photoshop, Illustrator source files. If the contract only transfers “the final website,” you don’t get the editable files. Demand them explicitly.
What you want in the contract: full assignment of all custom code written for your project, all custom design assets in their editable source format, and a license (not ownership, but a license) to use any pre-existing components in your finished product without restriction or future fees.
Also: confirm in writing that the developer will not reuse the bespoke design or custom code for a direct competitor in your industry for at least 12 months.
Need a contract template built around these protections?
7. Confidentiality, Data Protection, and Credentials Handling
You’re handing over passwords, customer data, possibly access to your CRM and analytics. The contract should treat that seriously.
Include:
- A mutual NDA covering business plans, pricing, customer lists, and unreleased products
- A clause requiring the developer to handle any personal data according to GDPR, CCPA, or your local equivalent — whichever applies
- A list of subcontractors or third parties who’ll have access, with a requirement that they sign equivalent confidentiality terms
- A 30-day post-termination obligation to return or delete all client data, credentials, and source files (with written confirmation)
The credentials part trips people up. Make sure the contract names every account the developer will create on your behalf — domain registrar, hosting, email, SSL, analytics — and confirms those accounts will be created under your name, your email, your billing, with admin access transferred to you at launch.
If the developer registers your domain on their account and disappears, you don’t own your domain. That happens more often than anyone admits.
8. Third-Party Assets, Licenses, and Liability
Who pays for the premium theme? The stock photos? The Google Maps API? The font license?
If the contract doesn’t say, default to: the client pays for assets they’ll own and use long-term; the developer pays for tools they use during the build. But spell it out.
Then add an indemnity clause that runs both directions:
- The developer indemnifies you if they use unlicensed code, stolen graphics, or pirated plugins that get you sued
- You indemnify the developer if you supply images or content you don’t have rights to
Both sides need this. Both sides forget to include it.
9. Warranties, Bug Fixes, and Post-Launch Support
The contract should specify:
- A warranty period (30, 60, or 90 days is normal) during which bugs in the developer’s code are fixed at no charge
- What counts as a “bug” — broken functionality versus new feature requests
- Response times for critical issues during the warranty (e.g., “site down” gets a 4-hour response)
- The hourly rate for support after the warranty expires, and whether a retainer is available
Then a liability cap. Developers will want their total liability capped at the project fee. That’s reasonable for honest mistakes. It’s not reasonable for gross negligence, IP infringement, or breach of confidentiality — make sure those exceptions are written in.
10. Termination, Kill Fee, and Exit Protocol
Both sides need a clean exit.
Cover:
- Termination for convenience: either party can end the project with 14 or 30 days’ written notice
- Termination for cause: immediate termination if the other side materially breaches and doesn’t fix it within a stated cure period (15 or 30 days is typical)
- Kill fee: if you terminate without cause, you pay for work completed plus a percentage of the remaining contract value (10–20% is standard)
- Handover obligations: regardless of who terminates, the developer must deliver all completed work product, source files, credentials, and a written status report within 14 days of termination
This is where your domain, hosting access, and source code either come home or get held hostage. Don’t sign without it.
11. Dispute Resolution and Governing Law
The cheapest dispute is the one you settle in writing. The next cheapest is mediation. After that, costs climb fast.
A balanced clause might read: any dispute first attempts good-faith negotiation between named representatives for 30 days; if unresolved, the parties submit to non-binding mediation; if still unresolved, arbitration or court in a named jurisdiction.
The jurisdiction matters. If you’re in Delhi and your developer is in Austin, fighting a case in Texas is a punishment by itself. Negotiate this before signing, not after.
Red Flags in a Developer Contract — A Quick Scan
Before you sign anything, scan for these phrases. Each one is a conversation worth having.
- “Developer retains ownership of all code and design pending negotiation of license terms”
- “Final payment due upon Developer’s notice of completion” (without defining completion)
- “Hosting will be provided through Developer’s account and billed annually” (lock-in)
- “Either party may modify scope by written notice” (no — only by mutual written agreement)
- “Developer’s liability is limited to $1” (yes, this happens)
- “Client waives all warranties, express or implied”
- “Auto-renewing maintenance retainer unless cancelled 90 days prior”
None of these are automatic deal-breakers. All of them deserve a slow, careful read and a counter-proposal.
What This Looks Like in Practice
A small e-commerce client came to us in 2025 after their previous developer launched their Shopify site, then quietly refused to hand over the theme files when the relationship ended. The contract said “ownership transfers upon final payment.” It didn’t say what “final payment” included. The developer argued the 30-day support invoice was part of “final payment” and held the files until it was paid — twice the original quote.
The client paid. They had no choice. The contract gave them no leverage.
A two-line addition to the contract — “Source files, including .liquid theme files and editable design assets, will be delivered within 5 business days of milestone 4 payment regardless of any subsequent support invoices” — would have prevented the entire mess.
That’s what a customer-protecting contract looks like. Specific. Boring. Effective.
Frequently Asked Questions
Is a web developer contract legally required?
No, but working without one is a bad idea. A written contract is what makes promises enforceable. Verbal agreements and email chains can technically be enforced, but proving terms is expensive and slow. For any project over a few hundred dollars, a signed contract pays for itself the first time something goes sideways.
Who should write the web developer contract — me or the developer?
The developer usually drafts it. You should always review, mark up, and negotiate it. If you’re not comfortable doing that yourself, run it past a contracts lawyer or a developer-experienced advisor. Most freelance and agency contracts are negotiable, even when they say “standard terms.”
What happens if there's no contract and the project goes wrong?
You’ll fall back on whatever your local jurisdiction says about implied service contracts. That usually means: the developer is owed reasonable payment for completed work, you’re owed reasonable quality, and ownership of the output is murky. Disputes get settled through small claims court, mediation, or chargebacks. None of these are fun. Get the contract.
Should I pay the full amount upfront?
No. A deposit of 20–30% is normal. Anything over 50% upfront with no milestone-based releases is a risk you don’t need to take. Tie payments to deliverables you can verify.
Do I own the code after I pay for it?
Only if the contract says so. Default IP law in most countries actually assigns copyright to the creator (the developer), not the person who paid. Your contract needs a clear assignment clause transferring full ownership to you upon final payment.
What's a fair revision policy in a web design contract?
Two to three rounds of revisions at each major stage (mockups, staging build) is standard. Each round should have a defined submission window. Revisions beyond that should be billed at a stated hourly rate. Vague phrases like “reasonable revisions” should be replaced with numbers.
Can the developer reuse my custom design or code for other clients?
Only if your contract lets them. A customer-protecting contract restricts reuse of bespoke work for direct competitors in your industry for a defined period — typically 12 months. Generic code libraries and methodologies are usually exempt and fair to allow.
What's the difference between a web developer contract and a web design contract?
In practice, very little — the same protections apply. A web design contract focuses on visual deliverables (mockups, brand assets, UI files), while a web developer contract leans heavier on code ownership, hosting, integrations, and technical warranties. Most modern projects combine both, and the contract should cover both sets of concerns.
How long should the warranty period be after launch?
Thirty to ninety days is normal. Sixty days is a reasonable middle ground for most business sites. The warranty should cover bugs and broken functionality in the developer’s code — not new features, content updates, or third-party plugin failures.
What should I do if my developer disappears mid-project?
If your contract has a termination-for-cause clause and a handover obligation, send written notice citing the breach, give them the cure period, then enforce the handover. If credentials and domain ownership are in your name (as they should be), you can switch developers without losing access. If they’re not, that’s the lesson — write it into the next contract.
Looking for a development partner who treats the contract as protection, not paperwork? Get in touch with the Truelysis team and we’ll walk you through how we structure agreements that hold up.