Why web development contracts fail agencies
Most contract disputes on web projects don’t start with bad faith. They start with assumptions. The client assumed revisions were unlimited. The agency assumed the client would provide content by a certain date. Neither assumption was written down, so when the project ran long or the invoice was disputed, there was nothing to refer back to.
A good web development contract is not primarily a legal document. It’s a communication tool. The act of writing out what is and isn’t included forces both sides to align on expectations before any work happens. That conversation, had at the proposal stage, prevents the harder conversation three months later when a project is overdue and over budget.
This checklist covers everything that should be in your standard contract, with notes on why each section matters and where agencies most often leave gaps.
Important: This article provides general guidance for agencies building contract frameworks. It is not legal advice. For contracts covering significant project values or complex terms, have a solicitor or attorney review the document before use.
The 12 sections every contract needs
A complete web development contract should cover these 12 areas. Each one addresses a specific category of dispute that commonly occurs on web projects.
List deliverables explicitly. Not “a website” but “a WordPress website comprising homepage, about page, services page, contact page, and a blog listing with individual post template.”
Define what is excluded. If copywriting, photography, logo design, or SEO are not included, say so. Clients often assume these come with the project unless told otherwise.
Specify the platform and technologies. WordPress, Shopify, Laravel, custom build. Name the version or major release where relevant.
List integrations in scope. CRM, email platform, payment gateway, booking system. Each integration is a delivery item and should be named.
Reference design assets. If designs are provided by the client, state that. If designs are included in the project, specify whether Figma files are delivered or only the built output.
Milestone-based schedule with trigger events. Payment should be tied to defined project events, not calendar dates. Calendar-based payments can create pressure to invoice before a milestone is genuinely complete.
Payment due date and late payment terms. State the number of days from invoice date (14 or 30 days is standard) and the consequence of late payment. A daily or monthly interest charge is standard in most jurisdictions.
Work stoppage clause. State that the agency may pause work if a payment milestone is overdue by more than a specified number of days. Without this, you may complete a project for a client who has not paid the midpoint invoice.
Currency and payment method. Specify the currency, accepted payment methods, and who bears transfer or transaction fees if cross-border payment applies.
Number of revision rounds per deliverable. Define how many rounds of feedback are included. Two rounds per major deliverable (design concept, development review) is typical. Be explicit that a “round” means one consolidated set of feedback.
Definition of a revision versus a new requirement. Changes to agreed content or minor adjustments to approved elements are revisions. A request to rebuild the navigation structure after design approval is a new requirement. Make this distinction clear.
Change request process and rate. Any work outside the agreed scope should go through a formal change request, documented in writing, with a quoted cost and client sign-off before work begins.
Project start date and estimated completion date. The start date should be conditional on receipt of the deposit and client onboarding materials, not just the contract signature.
Named milestones with estimated dates. Design approval, development completion, staging review, launch. Each milestone gives both sides a checkpoint to assess progress.
Dependency clause. State that the timeline is contingent on the client providing required materials (content, assets, credentials, feedback) within agreed response windows. Client-caused delays extend the timeline.
Content delivery deadline. Specify when all text, images, logos and brand assets must be delivered by the client, and the format required.
Feedback response window. State the maximum number of business days the client has to provide feedback at each review stage before the project timeline shifts.
Designated point of contact. Name who is authorised to give approvals and instructions on behalf of the client. Feedback from multiple stakeholders without a single point of approval is a common source of conflicting direction and rework.
Third-party account access. If the project requires access to existing hosting, domain, analytics, or third-party platforms, state that the client is responsible for providing this access promptly.
Transfer of IP upon final payment. State explicitly that ownership of the delivered work transfers to the client upon receipt of the final payment. Before that point, the agency retains ownership.
Third-party components remain under their own licences. Themes, plugins, stock photography, fonts and libraries are subject to their own licence terms. The agency is not transferring ownership of these, only the work that wraps around them.
Portfolio and case study rights for the agency. Reserve the right to display the completed project in the agency portfolio and case studies unless the client requires a confidentiality clause, in which case agree this separately.
Client warrants they own their supplied materials. The client must confirm they hold the rights to any content, images or brand assets they provide. This protects the agency from liability if a client provides materials they don’t have rights to use.
Define what constitutes launch readiness. Completion of agreed scope, client sign-off on staging, final payment received. All three should be required before launch.
Deemed acceptance clause. If the client does not provide written approval or specific objections within a set number of days after the staging review, the work is deemed accepted. This prevents projects sitting in review limbo indefinitely.
Hosting and domain responsibility at launch. State who is responsible for the hosting environment at launch, whether the agency is handing off to the client or setting up hosting as part of the scope.
Bug fix warranty period. State how long after launch you will fix bugs in the delivered work at no charge. Thirty days is common. Bugs are defects in the delivered scope, not new requirements.
What falls outside the warranty. Issues caused by client modifications, third-party plugin updates, or platform changes after handover are not covered under the bug fix warranty.
Ongoing support options. If you offer a maintenance or care plan, reference it here. Clients who know there is an option for ongoing support are more likely to take it up than those who are given no direction at handover.
Mutual NDA terms. State that both the agency and the client will keep each other’s business information and project details confidential. This is especially relevant when client businesses are in competitive markets.
White label sub-contractor clause. If you use a white label development partner to fulfil the project, include a clause stating that sub-contractors are engaged under confidentiality obligations. The client does not need to know who specifically is building, only that any sub-contractors are bound by the same confidentiality terms.
Cap total liability at the project fee. Limit your total liability to the value of the contract. Unlimited liability on a web project is not commercially reasonable and most clients will accept a capped limit.
Exclude consequential and indirect losses. Loss of revenue, data loss, or business interruption caused indirectly by the website are excluded from your liability. State this explicitly.
No guarantee of specific business outcomes. The agency delivers a website meeting the agreed technical and design specification. It does not guarantee specific traffic, conversion, or revenue outcomes.
Termination by either party with notice. State the notice period required for either party to terminate the agreement, typically 14 to 30 days written notice.
Payment for work completed to date. If the client terminates before completion, state that payment is due for all work completed to the termination date, calculated against the project rate or a stated hourly rate.
IP and files on termination. State what happens to files and work in progress if the contract is terminated before completion. Work completed and paid for transfers to the client. Unpaid work stays with the agency.
Termination for cause. Include a clause allowing immediate termination if a party materially breaches the agreement and does not remedy the breach within a reasonable time after written notice.
State the governing law. Name the country and state or jurisdiction whose law governs the contract. For international clients this should typically be your home jurisdiction.
Dispute resolution process. State that parties will attempt to resolve disputes by negotiation before escalating to formal legal proceedings. Some agencies include a mediation step as a mandatory first stage.
Written notice requirements. State that all notices under the contract must be in writing and sent to the addresses or email addresses listed in the agreement. This protects against disputes over whether a communication was made.
Payment milestone structures that work
The most common agency mistake on payment terms is loading too much of the fee into the final milestone. A 50-50 split (half on start, half on launch) looks simple but creates real risk. If the project stalls or the client becomes difficult near completion, you may have done most of the work before receiving half the fee.
These three structures work well for different project sizes.
| Structure | Milestone | % | Best for |
|---|---|---|---|
| Standard (3-stage) | Project kickoff (before work begins) | 40% | Most web projects under $20k |
| Design approval / staging delivery | 30% | ||
| Launch / final handover | 30% | ||
| Sprint-based (4-stage) | Project kickoff | 30% | Larger projects with defined sprint phases |
| Design sign-off | 25% | ||
| Staging environment delivered | 25% | ||
| Launch | 20% | ||
| Retainer (ongoing) | Monthly in advance | 100% | Ongoing maintenance, SEO or managed services |
| Additional work billed monthly in arrears | varies |
Scope creep: how to write the clauses that prevent it
Scope creep is the gradual expansion of a project beyond the original brief, usually without additional payment. It rarely happens all at once. It accumulates through small requests that each seem reasonable in isolation but add up to significant unbilled work.
The contract cannot prevent a client from asking for more. It can prevent you from delivering more without being paid for it. These are the specific clauses that create that protection.
State that no changes to the agreed scope are effective unless confirmed in writing by both parties. Verbal agreements on extra work, even if well-intentioned, are unenforceable and frequently misremembered. This one clause prevents many disputes.
Any out-of-scope request goes through a formal change request with a written description of the work, the additional cost, and the impact on timeline. The client must approve and sign the change request before any work begins. Do not start additional work on the expectation of approval.
Once a design is approved, requests to revisit fundamental design decisions are out of scope. State in the contract that written approval of a deliverable constitutes acceptance of that stage of work. Clients who later change their mind about approved direction are requesting new work, not a revision.
Content provided to the developer during the build phase should match the approved content. If the client replaces content after pages are built and the new content requires structural changes, those changes are out of scope. Make this explicit for ecommerce builds where product catalogues are often revised during development.
A request to change from WordPress to Shopify after development has started is not a revision. It is a new project. State that changes to the agreed technology stack after project commencement require a new agreement and will be treated as a separate project.
IP ownership and third-party licences
IP terms in web development contracts often contain two mistakes. The first is leaving ownership ambiguous. The second is treating all project components as if the agency can simply hand over full ownership.
Some components will always carry their own licence terms:
- WordPress plugins and themes are licensed under GPL, which has specific terms around distribution. The licence comes with the software, not the project.
- Shopify themes from the theme store are licensed to the account holder who purchased them. Agencies building with a purchased theme should transfer the licence or ensure the client purchases it directly.
- Stock photography carries per-use or subscription licences. The agency can use images under their subscription but cannot transfer those images to a client without the client holding their own licence.
- Commercial fonts have desktop and web licence distinctions. A font the agency uses in design files may require the client to hold a separate web font licence for ongoing use on the live site.
- Third-party APIs and services (mapping, payment processing, review platforms) have their own terms of service that govern use and cannot be assigned.
List these categories in your contract and be clear about which components transfer ownership and which are covered by third-party terms that remain with whoever holds the licence.
Client delays and project restart clauses
Client-caused delays are among the most common sources of project overruns, and most agencies absorb the cost without any contractual protection. The fix is straightforward: write it into the contract.
- Response window. The client must provide feedback or approvals within a stated number of business days (five to ten is typical). If they don’t, the project timeline shifts by the equivalent delay, at minimum.
- Content delivery deadline. Content not delivered by the agreed date pushes the launch date by the equivalent period. The agency is not responsible for launching a site with placeholder content because the client missed the content deadline.
- Idle project fee. If the project is paused due to client inaction for more than a stated period (often 30 days), the agency may charge a re-engagement fee to restart. This fee covers the overhead of context-switching back onto a paused project.
- Project abandonment. If the client has not been in contact for more than 60 days without agreed suspension, the project may be deemed abandoned. At this point the agency may invoice for all work completed to date and close the project. State this clearly.
Notes for agencies using white label partners
If you use a white label development partner to deliver projects, your client contract needs to account for this without disclosing the arrangement. Most clients do not need to know or care that a specialist team handles the build. What they need to know is that your agency is responsible for delivery.
A few contract points to address specifically:
- The agency is the sole responsible party. Your contract is between you and your client. Your arrangement with a white label development partner is separate. The client’s point of contact remains your agency throughout.
- Sub-contractor confidentiality clause. State that any third parties engaged to assist in delivery are bound by confidentiality obligations at least as strong as those in the client contract. This gives clients comfort without requiring you to name sub-contractors.
- NDA alignment. Your white label partner should sign an NDA before any client project details are shared. This should cover client names, project briefs, assets, and any other identifiable information. A reliable white label partner will have this as standard practice from the first conversation.
- Delivery accountability stays with you. If a deadline is missed or a deliverable has quality issues, your client’s recourse is with your agency. Your recourse with the sub-contractor is a separate matter managed independently.
Frequently asked questions
A web development contract should include a clear scope of work with deliverables listed, payment schedule with milestone triggers, revision policy with a defined number of rounds, intellectual property terms specifying when ownership transfers to the client, timeline with dependencies noted, content responsibility clause, launch conditions, post-launch support terms, liability limitation, and a termination clause covering both parties. Each section prevents a specific category of dispute that commonly occurs on web projects.
Ownership terms must be specified in the contract. The most common arrangement for agencies is that IP transfers to the client upon receipt of final payment. Until payment is received in full, the agency retains ownership. Third-party components such as themes, plugins, stock photography, and fonts are subject to their own licences and those licences belong to whoever purchased or holds them. Be explicit about each of these categories in the contract.
Define the number of revision rounds included in the project fee for each deliverable, what constitutes a revision versus a new requirement, and what the change request process and rate is for work outside the agreed scope. Two rounds of revisions per major deliverable is a common and reasonable standard. Without a defined revision policy, scope creep through unlimited feedback rounds is one of the most frequent causes of margin erosion on web projects.
A milestone-based payment structure works well for most web projects. A common split is 40% upfront before work begins, 30% at a defined midpoint such as design approval or staging delivery, and 30% on launch or final handover. The upfront payment should cover at minimum the first sprint of work to ensure the agency is not self-funding the project start. For larger projects, more granular milestones tied to specific deliverables give both parties clearer visibility and reduce the risk of large unpaid balances.
The contract should include a client delay clause stating that if the client does not provide required content, approvals or feedback within a specified number of business days, the project timeline shifts accordingly and the agency may charge a restart or re-engagement fee if the delay is extended. Without this clause, agencies absorb the cost of project restarts caused by client-side inaction, which is a common source of project overruns.