Web Development Contract
This Web Development Contract (this "Agreement") is made on between of (the "Client") and of (the "Developer").
The Client wishes to engage the Developer to build (the "Project"). The Developer agrees to carry out that work on the terms set out below. This Agreement replaces any proposal, quote or estimate previously exchanged, except where a document is expressly attached to and incorporated into this Agreement.
1. The Parties and the Engagement
The Client engages the Developer as an independent contractor, not as an employee, partner, agent or joint venturer. The Developer decides how, when and where the work is performed, supplies their own equipment and software, and is free to work for other clients during the term of this Agreement.
The Developer is responsible for their own taxes, insurance and any statutory contributions arising from payments under this Agreement, and is not entitled to employee benefits of any kind. Where the Developer uses a subcontractor for part of the Project, the Developer remains fully responsible to the Client for that work and for the subcontractor's compliance with this Agreement, including clauses 12 and 13.
Day-to-day contact for the Project is for the Client and for the Developer. Approvals, change requests and notices are only effective when sent in writing to those addresses.
2. Scope of Work and Deliverables
The Developer will build and deliver the following for the Project:
the features and functionality described in , built on ;
a working front end covering , responsive for desktop, tablet and mobile widths;
the back-end logic, database schema and any named in the specification;
a -environment setup — development, staging and production — with the completed Project deployed to ; and
source code delivered through a version-controlled repository, plus the written technical documentation described in clause 11.
3. Out of Scope
Anything not listed in clause 2 or in the specification referenced there is out of scope. For the avoidance of doubt, and unless the Parties agree otherwise in writing, the following are NOT included: visual design or UI design files beyond ; copywriting or content entry beyond ; native mobile applications; load testing or performance tuning beyond ; accessibility auditing or remediation beyond ordinary good practice; data migration from a legacy system beyond ; and ongoing hosting, monitoring or maintenance after the window in clause 14.
Where the Project requires paid third-party services or licences (hosting, domains, APIs, SaaS subscriptions, paid libraries or plugins), the Client pays for them directly and in the Client's own name. The Developer may purchase them on the Client's behalf only with prior written approval, in which case the cost is re-invoiced at cost plus .
4. Changes to Scope
Either Party may request a change to the scope at any time. A request becomes a change to this Agreement only when the Developer has provided a written change note stating the additional work, the additional fee, and the effect on the timeline, and the Client has approved that change note in writing.
Requests made in passing — in a call, a chat message or a comment on a ticket — are not change notes and create no obligation on the Developer to perform the work. Until a change note is approved, the Developer continues to work to the scope in clause 2, and no milestone date shifts as a result of the request.
Additional work approved under this clause is charged at unless the change note states a fixed price.
5. Timeline, Milestones and Approvals
The Project starts on and is scheduled to complete by . The Parties will work to the following milestones:
Technical specification and architecture approved by ;
Environments and repository set up, core data model built, by ;
Feature-complete build deployed to staging for review by ;
Testing and acceptance under clause 8 completed by ; and
Launch by .
6. Review and Approval Windows
The Client will review each milestone deliverable and either approve it or return consolidated written feedback within of delivery. Feedback returned after that window is treated as a new revision round under clause 8. If the Client does not respond within , the deliverable is deemed approved and the Developer may proceed to the next milestone.
Approval of a milestone means the Client accepts that deliverable as the basis for the work that follows. Revisiting an approved milestone later — for example asking for a different data model after development has moved past it — is a change to scope under clause 4, not a revision or a bug.
Timeline dates assume the Client meets its obligations under clause 7 and responds within the windows above. Delays caused by the Client extend every subsequent milestone date by at least the length of the delay, and the Developer may reschedule the remaining work to the next slot available in the Developer's calendar.
7. Client Materials, Content and Access
The Client will supply all text, data, media, brand assets and any other content required for the Project, in the formats reasonably requested by the Developer, by . The Client will also provide any access the Developer needs — hosting, domain registrar, source control, third-party API keys, and any existing system the Project integrates with — within of the Developer's written request.
If content or access is not supplied by the relevant deadline, the Developer may proceed using clearly marked placeholder content or mock data, and the affected milestone is treated as met for payment purposes. If the outstanding items remain outstanding for more than , the Developer may invoice all work completed to date, place the Project on hold, and charge a re-engagement fee of to restart it.
The Client warrants that it owns or is licensed to use everything it supplies, and that the Developer's use of that material in the Project will not infringe any third party's rights. The Client will indemnify the Developer against any claim arising from material the Client supplied.
8. Testing, Bugs and Revisions
The Developer will test each milestone deliverable against the acceptance criteria in the specification referenced in clause 2 before submitting it for Client review. The Client will carry out its own acceptance testing during the review window in clause 6 and report, in writing, any defect — meaning a failure of the delivered build to perform as described in the specification or to meet a documented acceptance criterion.
The fee in clause 9 includes rounds of revisions across the build. A round is one consolidated set of written feedback from the Client, delivered in a single response; the Developer will action that set in full before the next round begins. Revisions cover fixing a defect as defined above, or refinement of behaviour already delivered within the agreed scope; they do not cover a new feature, an additional integration, or a change to the data model or architecture, all of which are changes to scope under clause 4.
Revisions beyond the included rounds, and any revision requested after a milestone has been approved or deemed approved, are charged at per hour, billed in increments and invoiced monthly. The Developer will tell the Client in writing before starting work that will be charged at that rate.
9. Fees and Payment Schedule
The total fee for the Project is , exclusive of any sales tax, VAT or GST, which is added where applicable.
Invoices are payable within of the invoice date. Amounts unpaid after the due date carry interest at per month, or the maximum rate permitted by law if lower, accruing daily from the due date until payment is received. Bank transfer fees and currency conversion costs are the Client's responsibility.
If any invoice is more than overdue, the Developer may suspend all work and withhold delivery of code, repository access, staging access and launch until the account is settled in full. Time lost to a suspension extends the timeline, and the Developer is not liable for any consequence of a delay caused by non-payment.
The Client will pay the total fee as follows:
a non-refundable deposit of , invoiced on signature and payable before work begins;
on Client sign-off of the testing and acceptance step in clause 8; and
the balance of on completion, invoiced when the Project is ready for launch and payable before launch and before the transfer of ownership in clause 12.
10. Browser, Device and Technical Requirements
The Developer will build, test and support the completed Project on the current and immediately preceding major versions of , on , at viewport widths from upwards, and sized to support without dedicated performance tuning.
The Project is built to degrade gracefully elsewhere, but pixel-identical rendering and identical performance in every browser, version, device and network condition is not achievable and is not warranted. Support for a browser, device or load level outside those stated, and any load or security testing beyond ordinary good practice, is out of scope and is quoted separately as additional work under clause 4.
11. Launch, Handover and Credentials
When the final milestone is approved and all invoices due at that point have been paid, the Developer will deploy the Project to the production environment and hand over the Project. Handover comprises the deployed application, full access to the source-controlled repository (including commit history), any infrastructure-as-code or environment configuration used to run it, and written technical documentation covering the architecture, the data model, and how to deploy and operate the Project.
All hosting, domain, database, API and third-party service accounts used for the Project are registered in the Client's name and remain the Client's property. Where the Developer holds credentials for those accounts, the Developer will transfer or return them at handover and will delete any copy retained thereafter, other than what is held in the Developer's ordinary backups. Where an account was temporarily created by the Developer for convenience, the Developer will transfer ownership of it to the Client at handover.
The Client is responsible for the Project, its data and its accounts from the moment of handover, including hosting renewals, domain renewals, platform and dependency updates, and backups, except to the extent covered by clause 14.
12. Code Ownership and Intellectual Property Transfer
Until the Developer has received the total fee and every other amount due under this Agreement in cleared funds, the Developer retains full ownership of all source code, object code, database schemas, configuration and other materials produced for the Project. During that period the Client has a limited, revocable licence to review and test the work for the purpose of accepting it under clause 8, and no right to deploy it to production, distribute it, or use it for its own commercial benefit.
On receipt of final payment in full, the Developer assigns to the Client all right, title and interest in the custom code, database schema, and other work product written specifically for the Project (the "Custom Code"), including the copyright in it. The Developer will transfer the source-controlled repository, or grant the Client full ownership of it, as part of handover under clause 11, and will sign any further document the Client reasonably requires to give effect to this assignment.
Two things are excluded from that assignment and never transfer. First, third-party and open-source components incorporated into the Custom Code, which remain governed by clause 13 and are never owned by the Developer to assign. Second, the Developer's pre-existing and general-purpose materials — internal frameworks, boilerplate, component libraries, scripts, tooling and know-how the Developer brings to or develops for use across its business generally — in which the Client instead receives a perpetual, non-exclusive, royalty-free, worldwide licence to use, modify and operate as embedded in the Custom Code, without any right to resell or sublicense the pre-existing material on a standalone basis.
13. Third-Party Components and Open-Source Licensing
The Custom Code is likely to incorporate third-party and open-source software components (libraries, frameworks, packages and similar materials, together "Components"). At handover, the Developer will deliver a written list of every Component incorporated into the Project, its version, and the licence it is distributed under (an "attribution report"), generated from the Project's dependency manifest.
The Developer warrants that, to the best of its knowledge, no Component is distributed under a licence that would require the Client to disclose, distribute, or license the Custom Code itself under the same or a reciprocal open-source licence (a "copyleft" obligation, as under the GNU GPL or AGPL family of licences), unless the Developer has identified that Component in writing and the Client has approved its use in writing before it is incorporated. Where a Component requires an attribution notice, credit, or the inclusion of its licence text, the Developer will build that notice into the Project or its documentation, and the Client will preserve it and will not remove it without confirming the Component's licence permits removal.
The Client is responsible, from handover onward, for any Component's own usage limits, paid tiers, or renewal terms named in a Component's licence — the Developer's obligation under this clause is disclosure and licence-compatible selection, not ongoing account management. The Developer will indemnify the Client against any third party claim arising from the Developer's use of a Component in breach of that Component's own licence terms; the Client will indemnify the Developer against any claim arising from a Component the Client itself directed the Developer to use after a written warning under this clause.
14. Post-Launch Maintenance and Bug-Fix Window
For after launch (the "Maintenance Window"), the Developer will fix, at no additional charge, any defect — a failure of the delivered build to perform as described in the specification referenced in clause 2 or to meet a documented acceptance criterion under clause 8 — that the Client reports in writing during the Maintenance Window, using the same defect-report format used during testing.
The Developer will acknowledge a reported defect within and will fix a defect that prevents core functionality from working within , or a lower-severity defect within , of acknowledgement. Severity is assessed by the Developer, acting reasonably, and disputed severity assessments are resolved under clause 17.
The Maintenance Window does not cover: new features or scope changes (clause 4); design or content changes; work arising from changes the Client or a third party makes to the Project after handover; breakage caused by a third-party platform, API or Component update outside the Developer's control (clause 13); security vulnerabilities disclosed after handover, which are chargeable unless the Parties have a separate security-maintenance arrangement; or anything caused by content or data the Client supplied. Those are chargeable at the rate in clause 8.
Ongoing maintenance, hosting management, dependency and security patching, monitoring and backups after the Maintenance Window ends are not included in this Agreement. The Parties may agree a separate maintenance arrangement at per month.
15. Portfolio Rights and Credit
The Developer may display the Project — including screenshots, video, architecture descriptions, the live URL and a description of the work — in the Developer's portfolio, website, social channels, case studies and award or competition entries, and may describe the Client as a client. This right survives completion or termination of the Project and applies once the work is publicly launched or the Client has publicly announced it, whichever is earlier. It does not extend to disclosing the Custom Code itself, Client data, or any information the Client has marked confidential.
The Developer will not disclose any information the Client has marked confidential, or any commercially sensitive figures, without the Client's written consent. If the Client needs the Project kept confidential for a period, the Client must say so in writing before launch, in which case the Developer will delay any portfolio use until .
Notice of immunity under the U.S. Defend Trade Secrets Act (18 U.S.C. § 1833(b)), where that Act applies: an individual is not criminally or civilly liable under any federal or state trade secret law for disclosing a trade secret (a) in confidence to a federal, state or local government official, or to an attorney, solely to report or investigate a suspected violation of law, or (b) in a complaint or other document filed in a lawsuit or other proceeding, if the filing is made under seal. An individual who files a lawsuit against the Client for retaliation for reporting a suspected violation of law may disclose the trade secret to the individual's attorney and use it in the court proceeding, if any document containing it is filed under seal and it is not disclosed except under court order.
The Developer may place a discreet credit reading in the footer or an about/credits page of the Project. The Client may ask for it to be removed for a one-off fee of .
16. Termination and Kill Fee
Either Party may terminate this Agreement by giving written notice. Either Party may terminate immediately if the other commits a material breach that is not remedied within of written notice of it, and the Developer may terminate immediately if any invoice is more than overdue.
On termination for any reason the Client will pay, within : all fees for milestones already delivered or deemed approved; a pro-rata amount for work in progress on the current milestone, based on the Developer's reasonable assessment of the work completed; and any third-party costs the Developer has already committed on the Client's behalf. The deposit is non-refundable and is credited against those amounts — except that where the Developer terminates for convenience, or the Client terminates for the Developer's unremedied material breach, the Developer shall refund the part of the deposit that exceeds the amounts due under this clause.
If the Client terminates for convenience after work has begun, the Client also pays a kill fee of to compensate the Developer for the reserved capacity that cannot be resold at short notice. Ownership of Custom Code produced up to termination remains with the Developer unless every amount due under this clause is paid in full, in which case clause 12 applies to the Custom Code as it stands at termination.
17. Governing Law and General
This Agreement and any dispute arising out of it are governed by the laws of , and the Parties submit to the exclusive jurisdiction of the courts of . Before starting proceedings, the Parties will attempt in good faith to resolve the dispute by discussion between the named contacts in clause 1.
Except for the Client's payment obligations, either Party's indemnity obligations under clause 13, and either Party's liability for death, personal injury, fraud, or infringement of the other's intellectual property, each Party's total liability under this Agreement is limited to the total fee paid or payable by the Client, and neither Party is liable for loss of profit, revenue, data, goodwill or any indirect or consequential loss. Neither Party is liable for a delay caused by an event outside its reasonable control, provided it notifies the other promptly; this does not excuse an obligation to pay amounts due.
This Agreement is the entire agreement between the Parties about the Project and may only be amended in writing signed by both Parties, or by an approved change note under clause 4. Neither Party may assign it without the other's written consent, not to be unreasonably withheld. If any provision is held unenforceable, the rest continues in force, and a failure to enforce a provision is not a waiver of it. The Client's warranty and indemnity in clause 7, the indemnities in clause 13, clauses 12, 14, 15 and 16, and this clause survive termination, as does any obligation to pay an amount that accrued before termination.
18. Signatures and Date
This Agreement takes effect on the date of the last signature below, and neither Party is bound by it until both have signed. Until then it is a proposal only, and the Developer is under no obligation to begin work or hold capacity.
This Agreement may be signed in counterparts and by electronic signature, each of which is an original and all of which together form one agreement. The Parties agree that an electronic signature has the same effect as a handwritten one.
Each person signing below confirms that they have read this Agreement, agree to it, and are authorised to sign it on behalf of the party they represent.