ContractMaker Create a document

Free generator · editable · no signup

Website Development Scope of Work Template

Website development scope of work template, built in ContractMaker: fill in your project name, deliverables, timeline, and fee, and the generator outputs a finished Statement of Work in about 90 seconds.

A tight SOW prevents scope creep before the first commit is written. Get the project boundaries in writing before you touch the codebase.

Create yours free

Generate your website development scope of work template

Free · no signup · downloads instantly

Statement of work · tuned for website development scope of work template

The basics

23 sections · click any blank to fill it · hover a section to edit

Website Development Scope Of Work Template

1. Statement of Work / Scope of Deliverables

1.1 Governing SOW. The specific deliverables, features, technology stack, platforms, integrations, and milestones for this engagement are set forth in the Statement of Work attached hereto as Exhibit A (the "SOW"), which is incorporated by reference and made a part of this Agreement. In the event of a conflict between the body of this Agreement and any SOW, the SOW shall control solely with respect to the subject matter addressed therein. 1.2 Completeness of Deliverables. Provider shall deliver only those features, pages, screens, integrations, and functionalities expressly described in the SOW. Any feature, function, content element, third-party integration, platform, or deliverable not listed in the SOW is out of scope and shall not be provided under this Agreement without a fully executed Change Order as provided in Section 2. 1.3 Explicit Exclusions. Without limiting Section 1.2, the following are expressly excluded from the scope of this Agreement unless separately specified in the SOW or a Change Order: (a) SEO optimization, copywriting, or content creation beyond placeholder or seed content identified in the SOW; (b) third-party service fees, API subscription costs, domain registration, SSL certificates, or hosting fees; (c) training, documentation, or post-launch support beyond any maintenance period defined in the SOW; (d) data migration from legacy systems unless expressly itemized; (e) accessibility remediation beyond the WCAG compliance level specified in the SOW; and (f) compatibility with browsers, operating systems, or devices not identified in the SOW. 1.4 Technology Stack. Provider shall use the technology stack identified in the SOW. Material deviations from the specified stack require Client's prior written consent, which shall not be unreasonably withheld. 1.5 SOW Amendments. The SOW may only be amended through a signed Change Order executed by both parties. No verbal instruction, email direction, or other informal communication shall expand, modify, or supersede the SOW. 1.6 Client Responsibilities. Client shall furnish all materials, assets, credentials, and approvals identified as Client-supplied in the SOW by the dates specified therein. Provider's timeline obligations are tolled day-for-day for each day Client is in default of any material supply or approval obligation.

2. Change Order / Scope Change Control

2.1 Scope Lock. The SOW constitutes the complete and exclusive description of the work to be performed under this Agreement. No addition, deletion, or modification of scope takes effect unless documented in a Change Order signed by authorized representatives of both parties. 2.2 Change Order Process. Either party may propose a scope change by delivering a written change request to the other party's project contact. Within 3 business days of receipt, Provider shall deliver a written Change Order proposal specifying: (a) a description of the requested change; (b) any additions to or deletions from the deliverable list; (c) the additional or reduced fee, calculated at the rates set forth in the SOW or, if not specified, at per hour; (d) the revised milestone or delivery schedule; and (e) any impacts on dependencies, third-party integrations, or previously accepted work. The Change Order is not binding until signed by both parties. 2.3 No Work Until Signed. Provider shall not commence out-of-scope work until a Change Order is signed by both parties. Client shall not direct Provider to perform out-of-scope work orally or by informal communication, and any such direction does not create an obligation for Provider to perform or Client to pay. This Section constitutes a no-oral-modification clause within the meaning of applicable contract law. 2.4 Revision vs. New Work. A "Revision" is a modification to content or design within the scope of an already-approved deliverable that does not add functionality, pages, screens, integrations, or platform targets. "New Work" is any addition, substitution, or expansion that falls outside the approved deliverable list or requires material additional development effort. The SOW specifies the number of Revision rounds included at no additional charge for each deliverable. Additional Revision rounds beyond the included number are billed at the rate in Section 2.2(c) above. 2.5 Effect on Timeline. Each executed Change Order may extend affected milestone dates by the number of days necessary to accommodate the change, as specified in the Change Order. Changes that are additive to scope do not accelerate remaining milestone dates. 2.6 Pending Change Orders. While a Change Order is pending and unsigned, Provider may, at its election: (a) continue in-scope work unaffected by the proposed change; or (b) pause work on deliverables that depend on resolution of the pending change, without being deemed in breach, provided Provider notifies Client of the pause in writing within one business day.

3. Payment Schedule, Milestones & Late-Payment Rights

3.1 Fee. Client shall pay Provider the total fee set forth in the SOW (the "Project Fee") in accordance with the milestone schedule in Section 3.2. All amounts are in and are exclusive of applicable taxes. 3.2 Milestone Payment Schedule. Unless the SOW specifies a different schedule, the Project Fee is due as follows: (a) Deposit: % of the Project Fee is due upon execution of this Agreement. The deposit is non-refundable once Provider commences work and represents compensation for reserving Provider's capacity. (b) [Remaining milestones as specified in SOW.] 3.3 Late Payment. Invoices not paid within 30 days of invoice date will accrue interest at 1.5% per month (or the maximum rate permitted by applicable law, whichever is less) from the due date until paid in full. Provider may also suspend Services upon 5 business days' written notice if any invoice remains unpaid for more than 10 days after the due date. 3.4 Price Changes During Contract Term. Provider may not unilaterally increase fees for work covered by a signed SOW. For any renewal, extension, or new SOW entered into after the initial SOW term, Provider shall provide written notice of any fee change at least 30 days before the proposed effective date. If Client does not accept the new fees in writing and the parties do not agree on pricing within 15 days of notice, either party may decline to enter into a new SOW without penalty. 3.5 Price Cap for Maintenance and Retainer Engagements. For ongoing maintenance or retainer engagements that auto-renew under Section : (a) the monthly fee for any Renewal Term shall not exceed the current-term fee by more than % without Client's prior written consent; (b) if Provider's proposed renewal fee exceeds this cap, Client may terminate the maintenance engagement with 30 days' written notice without a kill fee, effective at the end of the current term; and (c) the CPI-based adjustment index used, if any, shall be the US CPI-U as published for the most recent 12-month period ending June of the renewal year. 3.6 Disputed Invoices. Client may withhold payment of a genuinely disputed invoice item by providing Provider with written notice of the dispute within 10 days of the invoice date, identifying the disputed amount and the basis for the dispute. Undisputed amounts must be paid by the original due date. The parties shall attempt to resolve the dispute within 14 days of the dispute notice.

4. Intellectual Property Ownership, Work-for-Hire Designation & Assignment

INTELLECTUAL PROPERTY OWNERSHIP (a) Background IP. Each party retains all right, title, and interest in its Background IP. "Background IP" means all intellectual property owned or licensed by a party prior to the Effective Date or developed independently of this Agreement. Each party grants the other a limited, non-exclusive, royalty-free license to use its Background IP solely to the extent necessary to perform or receive the Services during the term of this Agreement. (b) Deliverables — Work-for-Hire Designation. To the extent that any Deliverable constitutes a "work made for hire" as defined in 17 U.S.C. § 101 (including as a contribution to a collective work, as a part of a motion picture or other audiovisual work, as a translation, as a supplementary work, as a compilation, as an instructional text, as a test, as answer material for a test, or as an atlas), such Deliverable is a work made for hire for , and will be the author and owner of the copyright therein from the moment of creation. (c) Assignment. To the extent that any Deliverable does not qualify as a work made for hire, hereby irrevocably assigns to , effective upon receipt of full payment for such Deliverable, all right, title, and interest in and to such Deliverable, including all copyrights, patents, trademarks, trade secrets, and other intellectual property rights worldwide, in perpetuity. (d) License for Partially-Paid Deliverables. If this Agreement terminates before has paid in full for a Deliverable, grants a non-exclusive, non-transferable, revocable license to use that Deliverable solely for 's internal purposes until the outstanding balance is paid, at which point the assignment in Section (c) becomes effective. (e) Agency Portfolio License. grants a non-exclusive, royalty-free, perpetual license to display the Deliverables (excluding any Confidential Information) in 's portfolio, case studies, and marketing materials, unless notifies in writing that a specific Deliverable is subject to confidentiality restrictions. (f) Third-Party Content. will obtain all necessary licenses for third-party content (stock images, fonts, music, software) incorporated into Deliverables, and will disclose to any third-party license restrictions that limit 's use of the Deliverables. (g) Moral Rights. To the extent permitted by applicable law, waives all moral rights in the Deliverables in favor of . (h) Agency Tools & Methodologies. Notwithstanding the foregoing, retains all right, title, and interest in its proprietary tools, templates, methodologies, know-how, and general processes used to create the Deliverables. 's rights are limited to the Deliverables themselves.

5. Pre-Existing / Background IP Retention and License-Back

Pre-Existing / Background IP Retention and License-Back 1. Reservation of Background IP. Each party retains sole and exclusive ownership of all Intellectual Property Rights in works, inventions, methodologies, tools, frameworks, libraries, components, code bases, templates, and know-how that: (a) were created, developed, or acquired prior to the Effective Date; (b) are developed independently of this Agreement and the applicable SOW; or (c) are general-purpose tools or methodologies not created specifically for (collectively, "Background IP"). No assignment, transfer, or other conveyance of Background IP is intended or shall be implied by this Agreement. 2. Developer Background IP Schedule. 's Background IP incorporated into or required to operate the Deliverables is described in Schedule A – Background IP attached to the applicable SOW ("Developer Background IP"). shall update Schedule A prior to delivery of each Deliverable to reflect any additional Background IP incorporated during the engagement. 3. License Grant to Client. hereby grants a non-exclusive, royalty-free, irrevocable, worldwide, perpetual license to use, execute, and reproduce the Developer Background IP solely to the extent incorporated in, or reasonably necessary to operate, the Deliverables for 's internal business purposes (the "Background IP License"). The Background IP License does not include the right to: (a) sublicense, transfer, or assign the license except in connection with a permitted assignment of this Agreement; (b) use Developer Background IP in any product or service other than the Deliverables; (c) decompile, disassemble, or reverse-engineer any proprietary Developer Background IP beyond what is permitted by applicable law; or (d) use Developer Background IP to develop, train, or improve any competing product or service. 4. No Implied License. Except as expressly set out in Section 3, no license, right, or interest in 's Background IP is granted to , whether by implication, estoppel, or otherwise. 5. Foreground IP. All Intellectual Property Rights in works specifically created for under an SOW that are not Background IP ("Foreground IP" or "Deliverables IP") are governed by the IP Ownership / Work-for-Hire & Assignment clause of this Agreement.

6. Confidentiality / Non-Disclosure Obligation

CONFIDENTIALITY (a) Definition. "Confidential Information" means all non-public information disclosed by one party ("Discloser") to the other ("Recipient") in connection with this Agreement that is designated as confidential at the time of disclosure, or that a reasonable person would understand to be confidential given the nature of the information and circumstances of disclosure. Without limiting the foregoing, Confidential Information includes: business plans, financial data, pricing, fee structures, customer and prospect lists, proprietary methodologies, software, technical specifications, and personnel information. (b) Exclusions. Confidential Information does not include information that: (i) is or becomes publicly available through no fault of Recipient; (ii) Recipient already knew before receiving it from Discloser, as shown by written records; (iii) Recipient independently develops without use of or reference to the Confidential Information; or (iv) Recipient rightfully receives from a third party without restriction. (c) Obligations. Recipient will: (i) use Discloser's Confidential Information solely to perform or receive the Services under this Agreement; (ii) disclose it only to its employees, contractors, and advisors who have a need to know and who are bound by confidentiality obligations no less protective than this clause; and (iii) protect it with at least the same degree of care it uses for its own confidential information of similar sensitivity, but in no event less than reasonable care. (d) Compelled Disclosure. Recipient may disclose Confidential Information if required by law, court order, or regulatory authority, provided that Recipient: (i) gives Discloser prompt prior written notice to the extent legally permitted; (ii) cooperates with Discloser in seeking a protective order or other appropriate relief; and (iii) discloses only what is legally required. (e) Trade Secrets. Obligations with respect to information that constitutes a trade secret under applicable law (including the Defend Trade Secrets Act, 18 U.S.C. § 1836) will continue for as long as such information remains a trade secret, notwithstanding any shorter survival period stated below. (f) Subcontractors. may share 's Confidential Information with approved subcontractors solely to the extent necessary for them to perform work under this Agreement, provided each subcontractor is bound by written confidentiality obligations at least as protective as this clause. (g) Return or Destruction. Upon termination or expiration of this Agreement, or upon Discloser's written request, Recipient will promptly return or securely destroy all of Discloser's Confidential Information (including copies) and certify such return or destruction in writing, except as required by law or for legal-hold purposes. (h) Survival. This Section survives termination or expiration of this Agreement for a period of 3 years, except as provided in Section (e).

7. Acceptance Testing, Deemed Acceptance & Cure

Acceptance Testing, Deemed Acceptance & Cure 1. Acceptance Gates. The parties agree that the Deliverables will be reviewed and accepted in up to three (3) sequential stages (each, an "Acceptance Gate"), as identified in the applicable Statement of Work ("SOW") or project schedule: - Gate 1 – Design Comps: Static design mockups, wireframes, or visual prototypes submitted for approval prior to build. - Gate 2 – Staging Build: A fully functional version of the Deliverable deployed to a staging or test environment. - Gate 3 – Production Launch: The final Deliverable deployed to the production environment and ready for end-user access. Each Acceptance Gate corresponds to the payment milestone identified in the SOW. 2. Review Window. Upon 's written notification that a Deliverable is ready for review at an Acceptance Gate, shall have 5 business days (the "Review Window") to review the Deliverable and either (a) provide written acceptance, or (b) deliver a written deficiency report as described in Section 3. 3. Deficiency Reports. To reject a Deliverable, must deliver a written deficiency report within the Review Window that: (i) identifies each defect with sufficient specificity to allow to reproduce it; (ii) classifies each defect by severity tier in accordance with Section 5; and (iii) identifies the specific specification, SOW requirement, or Acceptance Criteria the Deliverable fails to meet. Subjective design preferences not documented in the SOW, Acceptance Criteria, or a signed change order do not constitute grounds for rejection. 4. Cure Period. Upon receipt of a conforming deficiency report, shall have 10 business days (the "Cure Period") to correct all identified Critical and Major defects and re-submit the Deliverable. The Review Window restarts in full upon re-submission. If fails to cure all Critical and Major defects within a second Cure Period, 's sole and exclusive remedy is, at 's election: (a) a pro-rata reduction in the fees attributable to the non-conforming Acceptance Gate only; or (b) termination of the SOW with respect to the uncompleted phase and a pro-rata refund of fees paid for that phase, net of the reasonable value of work delivered to date. 5. Defect Severity Tiers. | Tier | Definition | Cure Target | |------|-----------|-------------| | Critical | Defect that completely blocks a core function described in the SOW and has no reasonable workaround. | 5 business days | | Major | Defect that materially impairs a function described in the SOW but a reasonable workaround exists. | 10 business days | | Minor | Cosmetic defect, typographic error, or non-material deviation; does not block or materially impair function. | Addressed in next scheduled release or maintenance cycle. | A Deliverable shall be deemed accepted once all Critical and Major defects have been resolved. Minor defects do not block acceptance or withhold payment. 6. Deemed Acceptance. If does not deliver a conforming written deficiency report before the expiry of the Review Window, the Deliverable shall be deemed accepted as of the last day of the Review Window, and the associated payment milestone shall become immediately due and payable. Production use of any Deliverable by or its end users prior to formal acceptance shall also constitute deemed acceptance of that Deliverable. 7. Acceptance Criteria. The parties shall agree on objective Acceptance Criteria for each Acceptance Gate no later than after the Effective Date. Where Acceptance Criteria are not specified, the applicable standard is conformity with the functional and technical specifications set out in the SOW.

8. Client-Supplied Content: Obligations, Deadlines & Delay Consequences

and agree as follows regarding content that Client is responsible for supplying. 8.1 Content Schedule. Exhibit A (Content Deliverable Schedule) identifies each item of content Client must deliver, the responsible party, and the required delivery date (each, a "Content Due Date"). Content includes, without limitation, written copy, images, photographs, logos, brand guidelines, video files, product data, pricing information, third-party platform credentials, and any other materials the Project requires Client to supply. 8.2 Automatic Timeline Extension. For each business day Client's delivery of any content item is late past its Content Due Date, the Project Completion Date shall automatically extend by one (1) business day, without amendment, written notice, or further action required. Developer shall not be in breach of any project milestone or delivery obligation to the extent such delay is attributable to Client's late content delivery. 8.3 Escalation for Sustained Delay. (a) Notice Period (> 5 business days late). If Client has not delivered a required content item within 5 business days after its Content Due Date, Developer shall issue a written notice identifying the missing item(s) and the adjusted Project Completion Date. Developer has no obligation to proceed with dependent work until the missing content is received. (b) Suspension (> 15 calendar days late). If the missing content remains undelivered 15 calendar days after its Content Due Date, Developer may suspend all work on the Project by written notice. Immediately upon suspension, Developer will invoice Client for all fees earned through the suspension date (including the proportionate value of any in-progress milestones), which are due and payable within 30 days. Work will not resume until Client (i) delivers the outstanding content, (ii) pays all outstanding invoices, and (iii) pays a Reactivation Fee of to compensate Developer for re-onboarding, context rebuilding, and schedule disruption. (c) Deemed Abandonment (> 14 calendar days late). If the missing content remains undelivered 14 calendar days after its Content Due Date, the Project shall be deemed abandoned. All fees paid to Developer are non-refundable as compensation for work performed and opportunity cost. Developer shall have no further obligation to deliver any remaining Project milestone unless the parties execute a new written agreement. 8.4 Client Content Warranty. Client represents and warrants that all materials Client supplies under this Agreement: (a) are final, proofread, and in a format suitable for direct use in the deliverables; (b) are owned by Client or Client holds all licenses, rights, consents, and permissions necessary to use, reproduce, and publish the materials in the manner contemplated by this Agreement, including any third-party photographs, fonts, music, or other intellectual property; (c) do not infringe, misappropriate, or violate the intellectual property rights, privacy rights, or any other rights of any third party; and (d) do not contain defamatory, obscene, unlawful, or otherwise actionable content. 8.5 No Obligation to Verify. Developer has no obligation to proofread, spell-check, fact-check, or verify the accuracy, completeness, or licensing status of any Client-supplied content. Developer shall not be liable for any defect, claim, or loss attributable to errors, omissions, or rights issues in Client-supplied content. 8.6 Indemnification for Client Content. Client shall defend, indemnify, and hold harmless Developer from and against any third-party claim, demand, loss, damage, or expense (including reasonable attorneys' fees) arising from or relating to Client-supplied content, including claims of copyright infringement, trademark infringement, defamation, or invasion of privacy.

9. CMS / Repository Handover, Credentials Transfer & Training

9.1 Handover Obligation. Upon receipt of final payment in full, Developer shall deliver to Client all assets, credentials, and documentation identified in Exhibit C (Handover Checklist) within 10 business days (the "Handover Deadline"). The Handover Checklist shall include, at minimum: (a) all CMS administrator credentials and account transfer instructions; (b) all source code repositories in a format accessible to Client; (c) DNS records, domain registrar credentials, and hosting account access; (d) all API keys, OAuth tokens, and third-party service credentials created for the Project; (e) analytics platform access; (f) deployment documentation sufficient for a competent developer to redeploy the application independently; and (g) any other Project-specific credentials or assets listed in the SOW. 9.2 Training Session. As part of the Handover, Developer shall provide one (1) training session of up to 60 minutes via video conference, recorded at Developer's option. The session shall cover CMS content editing, media management, and basic administrative tasks relevant to the deliverables. Additional training sessions are out of scope and may be arranged under a separate Maintenance Agreement or at Developer's then-current hourly rate of . 9.3 Retention of Access After Handover. Developer shall retain no administrative or backend access to any Client system, repository, hosting environment, or third-party account after the Handover Confirmation (defined in Section 9.5) is signed, except as expressly agreed in a subsequent Maintenance Agreement. 9.4 Ongoing Support. Post-handover support, maintenance, updates, and bug fixes unrelated to the Developer's warranty obligations are not included in this Agreement and shall be governed by a separate Maintenance Agreement or invoiced at Developer's hourly rate of . 9.5 Handover Confirmation. Upon completing the handover, Developer will deliver a Handover Confirmation document listing each transferred item. Client shall review and countersign within 5 business days or notify Developer in writing of any missing item. Failure to respond within this period shall constitute Client's acceptance of the handover as complete. 9.6 Payment Condition. Developer is not obligated to deliver any credential, repository access, or asset identified in the Handover Checklist until Developer has received payment in full of all outstanding invoices under this Agreement. Withholding handover materials pending full payment does not constitute a breach by Developer.

10. Browser & Device Compatibility Matrix

10.1 Supported Environment Matrix. Developer warrants that the deliverables will function without material defect in the following browser and device environments (the "Supported Matrix") as of the Launch Date: | Browser | Versions Covered | |---|---| | Google Chrome | Current stable release and one prior major version | | Mozilla Firefox | Current stable release and one prior major version | | Apple Safari | Current stable release and one prior major version | | Microsoft Edge | Current stable release and one prior major version | | Device / OS | Coverage | |---|---| | iOS | and later, Safari and Chrome | | Android | and later, Chrome | | Desktop viewport | 1280px and wider | 10.2 Responsive Breakpoints. Developer warrants that the deliverables render without unintended horizontal scrolling or layout collapse at the following viewport widths: (a) 320px (mobile); (b) 768px (tablet); and (c) 1280px (desktop). Pixel-perfect rendering across all possible display densities, fonts, and zoom levels is expressly disclaimed. 10.3 Out-of-Scope Environments. Support for browsers, operating systems, devices, or viewport widths not listed in the Supported Matrix is expressly out of scope. Developer makes no warranty regarding functionality in Internet Explorer, Opera, or any browser version released after the Launch Date. Rendering or functional issues arising solely in unsupported environments are not defects under this Agreement. 10.4 Post-Launch Browser Updates. Browser and operating system vendors release updates outside Developer's control. If a post-Launch-Date browser or OS update causes a rendering or functional regression in the deliverables, remediation of that regression is not covered by Developer's warranty and shall be treated as a change-order request billed at Developer's hourly rate of . 10.5 Client Testing Obligation. Client is responsible for testing the deliverables in any environment not listed in the Supported Matrix prior to the Launch Authorization. Developer's warranty does not extend to environments that Client uses but that fall outside the Supported Matrix.

11. Launch Authorization / Go-Live Sign-Off

12.1 Pre-Launch Requirements. Developer will not publish the deliverables to a publicly accessible production environment until all of the following conditions have been satisfied (the "Launch Conditions"): (a) Client has reviewed the staging environment at the URL provided by Developer and confirmed in writing that the deliverables conform to the requirements of this Agreement; (b) Client has executed a Launch Authorization in the form attached as Exhibit D (the "Launch Authorization"); and (c) Developer has received final payment in full of all outstanding invoices under this Agreement, including any change-order invoices. 12.2 Effect of Launch Authorization. Client's execution of the Launch Authorization constitutes: (a) final acceptance of the deliverables as conforming to the Agreement; (b) authorization for Developer to publish the deliverables to the production environment; (c) commencement of the warranty period specified in the Agreement (the "Launch Date"); and (d) the moment at which risk and operational responsibility for the live production environment transfers to Client. 12.3 Developer Not Liable for Unauthorized Launch. If Client or any third party acting at Client's direction publishes or goes live with any portion of the deliverables without a signed Launch Authorization and receipt of final payment by Developer, Developer's warranty obligations are void as to any defects attributable to content, configuration, or modifications made outside of Developer's controlled staging environment. 12.4 Deemed Launch Authorization. If Client has completed the acceptance review process set forth in the Agreement and affirmatively approved the deliverables in writing, but has not executed the Launch Authorization within 10 business days of Developer's written request, Developer may, at its election, treat such approval as a duly executed Launch Authorization and: (a) proceed with publishing the deliverables to the production environment; or (b) terminate this Agreement and invoice Client for all fees earned through the date of termination, which are immediately due and payable. Developer shall provide Client 5 business days' written notice before exercising either option under this Section. 12.5 Post-Launch Responsibility. Following the Launch Date, Client is solely responsible for: (a) all content added to or modified on the live site; (b) third-party plugin, theme, or service updates initiated by Client; (c) hosting environment configuration changes; and (d) any impact of such actions on the deliverables' functionality or security. Developer's warranty does not cover defects caused by Client's post-launch modifications.

12. Third-Party Plugins, Themes, APIs & Dependency Risk Allocation

Third-Party Components; License Allocation; Dependency Risk 1. Identification of Third-Party Components. Prior to or concurrent with execution of the Statement of Work ("SOW"), Developer shall provide Client with a written schedule (the "Dependency Schedule") identifying all material third-party software, plugins, themes, libraries, APIs, SDKs, and other components (collectively, "Third-Party Components") that Developer reasonably anticipates incorporating into the Deliverables, together with the applicable license or subscription terms governing each component. The Dependency Schedule is incorporated into the SOW by reference. Developer shall promptly update the Dependency Schedule upon identifying any material new Third-Party Component during performance. 2. License Procurement — Client-Procures. (Client-Procures Model — insert if selected): For each Third-Party Component designated in the Dependency Schedule as requiring a paid license, Client shall procure, in its own name, all required licenses, subscriptions, and API keys before or promptly after execution of the SOW, and shall provide Developer with access credentials necessary to perform the Services. Developer is not responsible for the cost, procurement, renewal, or regulatory compliance of any Third-Party Component license. Developer shall use Third-Party Components only within the scope of the licenses provided by Client. (Agency-License Model — insert if selected): Developer may extend agency-tier or multi-site license access to Client for Third-Party Components held by Developer during the Engagement. Upon termination or expiration of this Agreement for any reason, such extended access shall automatically terminate, and Client shall procure its own licenses for any Third-Party Components it wishes to continue using within 30 calendar days following the effective date of termination. Developer shall have no liability for service interruptions, data loss, or functional degradation attributable to Client's failure to timely procure independent licenses. 3. Open-Source Components. The Dependency Schedule shall identify all open-source software incorporated into the Deliverables and the applicable open-source license (e.g., MIT, Apache 2.0, GPL v2/v3, LGPL) governing each component. Developer shall not incorporate any open-source component into the Deliverables in a manner that: (a) requires Client to release, license, or disclose Client's proprietary source code under an open-source license (including any GPL copyleft obligation) without Client's prior written consent; or (b) violates the terms of the applicable open-source license. Where a GPL-licensed theme or plugin is used, Developer shall disclose to Client any copyleft obligations that may apply to derivative works, including custom child themes or plugins, and obtain Client's written acknowledgment. 4. Post-Acceptance Dependency Changes. Developer does not warrant the continued availability, pricing, functionality, or terms of any Third-Party Component after the Acceptance Date. If, after the Acceptance Date, a Third-Party Component that is identified in the Dependency Schedule is deprecated, discontinued, materially modified, or made unavailable or economically impractical (including changes to API pricing, rate limits, or authentication requirements), and such change necessitates modifications to the Deliverables, such modifications shall be addressed through a Change Order and shall not constitute a warranty defect, provided that Developer's implementation of the affected component at the time of delivery was consistent with the component's then-current documentation and terms of use. 5. No Critical Single-Point-of-Failure Dependency. Without Client's prior written consent, Developer shall not architect the Deliverables such that a single Third-Party API, service, or component constitutes an unmitigated single point of failure for core functionality ("Critical Dependency"). Where a Critical Dependency is unavoidable or preferred by Client, Developer shall disclose such dependency in the Dependency Schedule, describe the associated risks in writing, and Client's written consent shall be documented in or attached to the SOW. 6. Developer's Compliance Obligation. Developer represents that, as of the Acceptance Date, Developer's use of each Third-Party Component in the Deliverables is consistent with the applicable license terms for such component. Developer's indemnification obligations under the Agreement with respect to third-party intellectual property claims shall not extend to claims arising from Third-Party Components themselves (as distinct from Developer's non-compliant use thereof), except to the extent such claims arise directly from Developer's material breach of a Third-Party Component's license terms.

13. Accessibility (WCAG / ADA) Responsibility Allocation

Accessibility Standards; Scope of Warranty; Legal Compliance Allocation 1. Accessibility Scope. Developer shall design and build those components of the Deliverables expressly listed in the Accessibility Scope Exhibit attached to the SOW ("In-Scope Components") with the objective of conforming to the Web Content Accessibility Guidelines (WCAG) Level AA as published by the World Wide Web Consortium (W3C) at the time of delivery. The Accessibility Scope Exhibit shall identify each In-Scope Component with specificity (e.g., custom theme templates, primary navigation, contact and checkout forms, core page layouts) and shall identify Out-of-Scope Components as described in Section 3. 2. Testing and Documentation. Upon completion of In-Scope Components and prior to requesting formal acceptance, Developer shall conduct accessibility testing using (or a substantially equivalent automated testing tool), document the results, and provide Client with a written Accessibility Conformance Report ("ACR") summarizing findings and any known residual issues. The ACR is not a legal compliance certification. 3. Out-of-Scope Components. Unless expressly listed as In-Scope in the Accessibility Scope Exhibit, the following are excluded from Developer's accessibility warranty: (a) third-party plugins, embeds, widgets, or iframes (including but not limited to payment processors, social media feeds, live chat widgets, mapping services, and marketing automation tools); (b) content, documents, images, video, audio, or other media uploaded or added by Client or Client's users after the Acceptance Date; (c) client-provided PDF, Word, or other document files and the platforms used to render them; (d) embedded video players and third-party streaming content (Client is solely responsible for providing captions and audio descriptions for such content); (e) components built or customized by Client or third parties after the Acceptance Date; and (f) any component the parties have agreed in writing to exclude. 4. No Statutory Compliance Warranty. Developer warrants only that In-Scope Components will conform to the WCAG Level AA technical standard as measured by the agreed testing methodology at the time of delivery. Developer makes no representation or warranty, express or implied, that WCAG conformance constitutes compliance with the Americans with Disabilities Act (ADA), Section 508 of the Rehabilitation Act, the Accessibility for Ontarians with Disabilities Act (AODA), or any other applicable accessibility statute, regulation, or legal standard. Responsibility for legal compliance with applicable accessibility laws rests solely and exclusively with Client as the website owner and operator. 5. Post-Delivery Content and Modifications. Client acknowledges that accessibility conformance of the Deliverables may be affected by content Client adds after the Acceptance Date, by Client's use of third-party components, or by modifications made by Client or third parties. Developer's accessibility warranty does not extend to any such content, components, or modifications. 6. Client Indemnification. Client shall indemnify, defend, and hold harmless Developer and its officers, directors, employees, and agents from and against any third-party claims, proceedings, fines, penalties, damages, and costs (including reasonable attorneys' fees) arising out of or relating to: (a) Client's content or specifications that affect accessibility of the Deliverables; (b) Out-of-Scope Components; (c) modifications to the Deliverables made by Client or at Client's direction after the Acceptance Date; or (d) Client's failure to comply with any applicable accessibility statute or regulation. This indemnification obligation is subject to Client receiving prompt written notice of any claim and having the right to participate in the defense thereof. 7. Warranty Remedy. If, within 90 days following the Acceptance Date, Client provides Developer with written notice and reproducible evidence that an In-Scope Component fails to conform to WCAG Level AA as measured by , Developer's sole obligation shall be to use commercially reasonable efforts to correct the non-conformity. This remedy is Client's exclusive remedy for Developer's accessibility warranty obligations.

14. Hosting, Domain Registration & Infrastructure Responsibility

9. Hosting, Domain Registration & Infrastructure Responsibility 14.1 Definitions. For purposes of this Section: (a) "Infrastructure Accounts" means all accounts, credentials, and services required to operate the Deliverables in a live environment, including without limitation domain registrar accounts, web hosting accounts, cloud-hosting or virtual-private-server accounts, content-delivery-network (CDN) accounts, DNS management accounts, SSL/TLS certificate accounts, email-hosting accounts, and any third-party platform accounts (collectively, "Accounts") together with all associated login credentials, API keys, and renewal billing arrangements. (b) "Transfer" means the assignment of ownership, billing responsibility, and administrative control of an Account to a specified party. 14.2 Selected Infrastructure Model. The parties shall select one of the following models by initialing the applicable option in the Cover Sheet or Statement of Work. If no selection is made, Model A (Client-Owned Infrastructure) applies by default. ☐ Model A — Client-Owned Infrastructure (Section 14.3) ☐ Model B — Developer-Provisioned, Then Transferred (Section 14.4) ☐ Model C — Managed Hosting Package (Section 14.5) 14.3 Model A — Client-Owned Infrastructure. (a) Client responsibility. Client shall, prior to the commencement of the build phase, establish and maintain all Infrastructure Accounts in Client's own legal name and at Client's sole expense. Client is responsible for all registration fees, renewal fees, hosting fees, and any charges imposed by third-party providers. (b) Developer access. Client shall grant temporary administrative access to the Infrastructure Accounts necessary to complete the Deliverables. Such access shall be limited to the scope required for the project and shall be revoked by Client no later than 3 business days following final delivery and acceptance of the Deliverables, or upon earlier termination of this Agreement, whichever occurs first. (c) Developer not responsible for third-party provider failures. has no liability for domain expiry, lapse in hosting service, data loss, outages, security breaches, or any other failure attributable to a third-party hosting provider, domain registrar, CDN, or any other Infrastructure Account provider. Client is solely responsible for maintaining current payment methods and renewal schedules with all such providers. (d) Credentials security. Client shall not share Infrastructure Account credentials with through insecure channels. The parties shall use a mutually agreed credential-sharing method (e.g., a password manager with granular access controls). shall not store Client credentials beyond the duration of the engagement and shall confirm deletion of credentials in writing within 5 business days of project completion or termination. 14.4 Model B — Developer-Provisioned, Then Transferred. (a) Provisional registration. shall, on Client's behalf and at Client's direction, provision the Infrastructure Accounts described in the applicable Statement of Work. All registration and hosting fees advanced by shall be reimbursed by Client within 30 business days of invoice. Client acknowledges that Infrastructure Accounts provisioned under this Model may be registered initially in 's name or under a reseller account solely for administrative convenience and that beneficial ownership and all associated rights vest exclusively in Client from the date of provisioning. (b) Transfer upon final payment. Within 5 business days following (i) receipt by of all outstanding fees under this Agreement and (ii) the launch or delivery of the Deliverables, shall Transfer all Infrastructure Accounts to credentials designated in writing by Client. Transfer shall include, at minimum: (A) domain registrar account transfer or registrar-lock removal and authorization code (EPP code) delivery; (B) hosting account migration or access Transfer to Client-specified login credentials; (C) delivery of all DNS zone file records; and (D) delivery of all SSL/TLS certificate files and private keys (where transferable). (c) Post-transfer cooperation. Following Transfer, shall provide reasonable written assistance and answer reasonable technical questions regarding the Infrastructure Accounts at no additional charge for a period of 10 business days. Assistance required beyond this period may be billed at 's then-current hourly rate. (d) No withholding. shall not withhold, delay, or condition any Transfer of Infrastructure Accounts on any basis other than Client's satisfaction of its outstanding payment obligations under this Agreement. Notwithstanding any payment dispute, shall not allow any domain name to lapse, expire, or be transferred to a third party without Client's prior written consent. (e) Failure to complete transfer. If fails to complete Transfer within the period specified in Section 14.4(b) and Client has satisfied all payment obligations, Client may, after written notice providing 10 additional business days to cure, seek specific performance in addition to any other remedies available at law or equity. 14.5 Model C — Managed Hosting Package. (a) Separate hosting agreement. Where provides ongoing hosting services to Client, such services shall be governed exclusively by a separate written Hosting and Maintenance Agreement ("HMA") entered into by the parties, which shall specify uptime service-level commitments, backup frequency and retention, security-patching obligations, support response times, fee schedule, and minimum notice period required for termination. (b) Scope of this Agreement. This Agreement covers only the design, development, and delivery of the Deliverables and does not create any warranty, representation, or obligation regarding hosting availability, uptime, performance, or data preservation. No service-level commitment of any kind is implied by this Agreement with respect to the hosting environment. (c) HMA required before launch. shall not launch the Deliverables to a production environment under this Model unless an executed HMA is in place. If Client elects to terminate the HMA, shall, within 20 business days of the effective date of termination, Transfer all Infrastructure Accounts and Deliverables to Client-specified credentials and hosting environments, provided Client has satisfied all outstanding payment obligations under both this Agreement and the HMA. (d) No lock-in. The existence of a HMA does not limit Client's right to take ownership of the Deliverables and migrate to a hosting provider of Client's choice upon termination of the HMA in accordance with its terms. 14.6 General Provisions (All Models). (a) Domain ownership. Regardless of which Model applies, the domain name(s) listed in Exhibit are and shall remain the exclusive property of Client. acquires no ownership interest in any domain name as a result of this Agreement. (b) No agency. Where acts on Client's behalf in registering domains or provisioning accounts, acts as Client's limited agent for that administrative purpose only and not as a general agent or fiduciary. (c) Data portability. Upon project completion, termination, or Client's request, shall provide Client with a complete export of all site content, media, databases, configuration files, and code comprising the Deliverables in a standard, machine-readable format within 5 business days. (d) Survival. The obligations in this Section 14 survive expiration or termination of this Agreement.

15. Limitation of Liability & Consequential Damages Exclusion

LIMITATION OF LIABILITY (a) Exclusion of Consequential Damages. To the fullest extent permitted by applicable law, neither party will be liable to the other for any indirect, incidental, special, consequential, punitive, or exemplary damages — including lost profits, lost revenue, loss of business opportunity, loss of data, or harm to reputation — arising out of or related to this Agreement, even if the party has been advised of the possibility of such damages and even if a limited remedy fails of its essential purpose. (b) Aggregate Cap. Each party's total aggregate liability to the other arising out of or related to this Agreement — whether in contract, tort (including negligence), strict liability, or otherwise — will not exceed the total fees actually paid or payable by to during the -month period immediately preceding the event giving rise to the claim, or , whichever is greater. (c) Exceptions. The limitations in Sections (a) and (b) do not apply to: (i) a party's obligation to indemnify the other for third-party claims of intellectual property infringement under the Mutual Indemnification clause; (ii) liability arising from a party's gross negligence or willful misconduct; (iii) a party's obligations under the Data Protection and Confidentiality clauses with respect to a data breach caused by that party's failure to maintain reasonable security; or (iv) a party's obligation to pay amounts owed under this Agreement. (d) Basis of the Bargain. Each party acknowledges that the limitations in this Section reflect a reasonable allocation of risk, are an essential element of the basis of the bargain between the parties, and that would not have entered into this Agreement without these limitations.

16. Governing Law, Jurisdiction & Venue

GOVERNING LAW; JURISDICTION; VENUE (a) Governing Law. This Agreement and any dispute arising out of or related to it — including its formation, interpretation, performance, breach, or termination — will be governed by and construed in accordance with the laws of the State of , without regard to its conflict-of-law provisions. (b) Consent to Jurisdiction. Each party irrevocably submits to the exclusive personal jurisdiction of the state and federal courts located in County, for any action or proceeding arising out of or relating to this Agreement that is not subject to arbitration under the Dispute Resolution clause (if any). (c) Venue. Each party waives any objection to the laying of venue in the courts identified in Section (b), and waives any claim that such courts are an inconvenient forum. (d) Service of Process. Service of process in any such action may be made by any method authorized by the applicable court rules or by mailing a copy of the summons and complaint by registered or certified mail, return receipt requested, to the party's address set forth in this Agreement. (e) Prevailing Party. In any dispute arising under this Agreement, the prevailing party is entitled to recover its reasonable attorneys' fees and costs from the non-prevailing party, unless the parties have agreed to a different allocation in the Dispute Resolution clause.

17. Dispute Resolution — Escalation Ladder (Negotiation → Mediation → Arbitration/Litigation)

DISPUTE RESOLUTION (a) Good-Faith Negotiation. Before initiating any formal dispute proceeding, the parties will attempt to resolve any dispute, controversy, or claim arising out of or relating to this Agreement ("Dispute") through good-faith negotiation. Either party may initiate this step by delivering written notice to the other describing the Dispute in reasonable detail ("Dispute Notice"). Senior representatives of each party with authority to resolve the Dispute will meet (in person, by phone, or by videoconference) within 10 business days of the Dispute Notice and attempt to resolve the matter in good faith for a period of 30 business days from the date of the Dispute Notice (or longer, if agreed in writing). (b) Mediation. If the Dispute is not resolved through negotiation within the timeframe in Section (a), either party may submit it to non-binding mediation administered by (or, if the parties cannot agree on a provider, by the American Arbitration Association under its Commercial Mediation Procedures). The mediation will take place in , . The parties will share mediator fees equally. Each party will bear its own legal fees for the mediation. (c) Binding Arbitration. If the Dispute is not resolved through mediation within 60 days after the appointment of the mediator, either party may demand binding arbitration. Arbitration will be administered by under its then-current , before a single arbitrator. The arbitration will take place in , . The arbitrator's decision will be final and binding and may be entered as a judgment in any court of competent jurisdiction. The parties agree that the arbitration — including its existence, proceedings, and any award — is confidential. (d) Exceptions to Arbitration. Either party may seek emergency injunctive or other equitable relief from a court of competent jurisdiction without first completing the negotiation or mediation steps, to prevent irreparable harm — including to protect Confidential Information or intellectual property — pending the outcome of arbitration. (e) Small Claims. Either party may bring a Dispute in small claims court if the amount in controversy falls within that court's jurisdictional limit. (f) Class Action Waiver. Each party waives any right to bring or participate in any class action, class arbitration, or representative proceeding relating to this Agreement. (g) Governing Law for Arbitration. The arbitration will be governed by the Federal Arbitration Act (9 U.S.C. §§ 1–16) and, where not preempted, by the laws of .

18. Assignment

18.1 General Restriction. Neither Party may assign, delegate, or transfer any of its rights or obligations under this Agreement, in whole or in part, without the other Party's prior written consent, which will not be unreasonably withheld or delayed. 18.2 M&A Exception. Notwithstanding Section 18.1, either Party may assign this Agreement without consent in connection with a merger, acquisition, change of control, or sale of all or substantially all of the assets to which this Agreement relates, provided that: (a) the assignee assumes all obligations of the assigning Party under this Agreement; and (b) the assigning Party provides the other Party written notice within thirty (30) days of the assignment. 18.3 Void Assignment. Any purported assignment in violation of this Section is void. 18.4 Binding Effect. This Agreement is binding upon and inures to the benefit of the Parties and their permitted successors and assigns.

19. Notices

19.1 Form. All notices, requests, demands, consents, and other communications required or permitted under this Agreement ("Notices") must be in writing. 19.2 Delivery Methods. Notices may be delivered by: (a) personal delivery; (b) nationally recognized overnight courier (e.g., FedEx, UPS); (c) certified or registered mail, return receipt requested, postage prepaid; or (d) email to the address specified below, provided that the sender retains proof of transmission and does not receive an automated bounce or delivery-failure notification within twenty-four (24) hours. 19.3 Effectiveness. Notices are effective: (a) upon personal delivery; (b) one (1) business day after deposit with overnight courier; (c) three (3) business days after deposit in the mail; or (d) on the day of email transmission if sent by 5:00 PM recipient's local time on a business day, or on the next business day if sent after 5:00 PM or on a non-business day. 19.4 Addresses. To Provider: , , Email: To Customer: , , Email: Either Party may change its notice address by providing written notice to the other in accordance with this Section.

20. Severability

If any provision of this Agreement is held by a court of competent jurisdiction to be invalid, illegal, or unenforceable under applicable law, that provision will be: (a) modified to the minimum extent necessary to make it valid, legal, and enforceable while preserving the Parties' original intent; or (b) if modification is not possible, severed from this Agreement. The validity, legality, and enforceability of the remaining provisions will not in any way be affected or impaired. The Parties agree to negotiate in good faith a replacement provision that, to the greatest extent possible, achieves the intended commercial purpose of the severed provision.

21. Entire Agreement (Integration)

21.1 Integration. This Agreement, together with all SOWs, Change Orders, and exhibits executed hereunder, constitutes the entire agreement between the Parties with respect to its subject matter and supersedes all prior and contemporaneous agreements, negotiations, representations, warranties, and understandings, whether written or oral, relating to the same subject matter. 21.2 No Oral Modifications. No oral statement, prior course of dealing, trade usage, or conduct will be used to supplement, interpret, or contradict the written terms of this Agreement. 21.3 Purchase Orders. Any terms set forth in Customer's purchase orders, vendor registration forms, or similar documents are of no force or effect and do not modify this Agreement unless expressly incorporated into a signed SOW or Change Order. 21.4 Results Representations. Customer acknowledges that no employee, agent, or representative of Provider has authority to guarantee specific results or outcomes, and that any such representation made outside this Agreement is not binding on Provider.

22. Electronic Signature & Counterparts

22.1 Electronic Signatures. This Agreement and any SOW or amendment may be signed by electronic signature, including signatures created through or any other electronic signature service compliant with the Electronic Signatures in Global and National Commerce Act (E-SIGN Act), 15 U.S.C. § 7001 et seq., and the Uniform Electronic Transactions Act (UETA) as enacted in the applicable jurisdiction. Electronic signatures have the same legal effect as original handwritten signatures. 22.2 Counterparts. This Agreement may be executed in one or more counterparts, each of which will be deemed an original, and all of which together will constitute one and the same instrument. Delivery of an executed counterpart by electronic transmission (including PDF or electronic signature platform delivery) is equally effective as delivery of a manually executed counterpart.

23. Order of Precedence

In the event of a conflict between documents comprising this Agreement, the following order of precedence applies (highest to lowest): (1) any executed Change Order, but only with respect to the specific provision it expressly modifies; (2) the applicable Statement of Work (SOW), but only with respect to the specific Services it covers; (3) the Cover Page (if applicable); (4) these Standard Terms. This order of precedence does not apply to Section [limitation-of-liability] or Section [disclaimer-of-warranties], which control in all cases notwithstanding any contrary term in an SOW or Change Order unless the SOW or Change Order expressly states that it increases the liability cap.

Exhibit A — Services

This Statement of Work governs the website development engagement as described herein, including page inventory, functional requirements, CMS configuration, browser and device compatibility matrix, content supply schedule, milestone dates, acceptance criteria, and launch checklist. This SOW is subordinate to the parties' master web development agreement.

ContractMaker is a document tool, not legal advice. Review every document, and consult a qualified lawyer for important or high-value agreements. See our Terms.

A Website SOW Built for Real Dev Projects, Not Generic Work

Web projects drift. A vague scope means endless revision requests, moving goalposts, and invoices that are hard to defend. A website development scope of work locks in exactly what you are building, what is out of scope, and when each deliverable lands.

ContractMaker handles the document structure. Acceptance windows and a change-order clause are already part of the template, so the client sees clear project boundaries from day one, not after the first disagreement.

What Your Website SOW Covers

The generator captures everything a web project agreement needs to protect both the developer and the client.

  • Provider and client names, project name, and start date
  • Deliverables list: pages, features, integrations, and what is explicitly excluded
  • Milestone schedule with specific completion dates
  • Fee breakdown and the payment trigger tied to each milestone
  • Acceptance window so the client has a defined review period
  • Change-order clause: work outside scope requires a new agreement before it starts
  • Governing law for dispute resolution

See your document before you send it

Fill the fields on the left and the full agreement builds on the right in real time. Read every clause, change any answer, and download a clean PDF when it looks right.

Customize any clause without legal training

A vetted base template handles the structure, so you are never starting from a blank page.

Change the scope, the payment schedule, or the terms by editing plain fields, not legalese.

The tool fills deterministic blanks and never invents clauses, so the document stays sound.

  • Plain-language fields instead of legal jargon
  • Deposit, milestone, or net-30 payment terms
  • Add scope, deliverables, and revision limits
  • Set who owns the work once it is paid for

One tool for every client document you send

ContractMaker covers the documents independent professionals send most:

  • Service agreements and freelance contracts
  • Project proposals and statements of work
  • Retainer agreements for ongoing work
  • Mutual NDAs and confidentiality terms
  • Change orders and deposit terms
  • Model, talent, and property releases

A document tool, not a law firm

Good client paperwork should not need a lawyer on call or an hour of your day.

ContractMaker gives you a clean, vetted document in about 90 seconds, built for the work you actually do.

Every document saved and ready to reuseComing soon

Nothing you create gets lost, since each document is saved to your account.

Reopen a past agreement, duplicate it for a new client, and change only what is different.

Your business details and favorite clauses are remembered for next time.

  • A library of every contract and proposal you make *
  • Duplicate and reuse in seconds for the next client *
  • Saved business profile and reusable clause libraries *
  • Branded documents with your name and logo

* In development, coming soon. Today you can fill the form and download your document.

Send, sign, and store in one placeComing soon

Take the document from draft to signed without leaving ContractMaker:

  • Download a clean PDF or copy the text
  • Collect a legally binding e-signature online *
  • Track when a client opens and signs *
  • Keep every signed copy in one client portal *

* In development, coming soon. Today you can download a clean PDF or copy the text.

Your next contract is one form away

Stop rewriting the same agreement for every client. Fill a few fields, download a polished document, and send it today. Free to start, no signup required.

Create yours free

Frequently asked questions

Is a website development scope of work template legally binding?

Once both parties sign, a clear written SOW is generally enforceable. ContractMaker is a document tool, not legal advice. For complex builds with large budgets, have a lawyer review before work begins.

Should I use an SOW or a full service agreement for a web project?

An SOW defines exactly what is delivered for one project. A service agreement covers the broader client relationship, including IP, confidentiality, and liability. For a single website build, an SOW combined with a master service agreement gives you the cleanest coverage.

How do I handle client requests that go beyond the original scope?

The SOW includes a change-order clause. Any work outside the agreed deliverables is treated as a new scope item with its own fee and timeline, signed off before you start it.

Is the document ready to send?

Yes. You get a clean, formatted document you can download, print, and send right away. No watermark, no signup.

Do I need a lawyer?

ContractMaker is a document tool, not legal advice. The base templates are vetted and openly licensed, but for high-stakes or unusual situations you should have a lawyer review your final document.

Is it really free?

Yes. Every document is free to generate and download, with no watermark and no signup. Fill the fields, download the file, and send it.

Can I edit the wording?

You control every field, so the scope, payment terms, and clauses always match how you work.