<!--
  Statement of Work (SOW) Template
  A DevShopVault template. Year: 2026.
  This is a practical template, not legal advice; have a lawyer review before use.
-->

# Statement of Work

**This Statement of Work ("SOW")** is entered into as of [Effective Date] by and between:

- **Client:** [Client legal name], [entity type], of [address] ("Client")
- **Agency:** [Agency legal name], [entity type], of [address] ("Agency")

This SOW is governed by the Master Service Agreement between the parties dated [MSA date]. If no MSA exists, this SOW is the full agreement between the parties for the work described below.

---

## 1. Background and objective

[One or two sentences on the client's situation and the outcome this engagement delivers. Example: "Client operates a logistics business and needs a customer-facing web application that lets shippers request, track, and pay for freight, with an AI assistant that answers status questions from live data."]

**Primary objective:** [The single most important result the software must produce.]

---

## 2. Scope of work

### 2.1 In scope

The Agency will design, build, and deliver the following:

1. [Feature or workstream 1, described so both parties can tell when it is done.]
2. [Feature or workstream 2.]
3. [Feature or workstream 3.]
4. [Integrations: list each third-party system, e.g. Stripe payments, email provider, auth provider.]

### 2.2 Out of scope (explicitly excluded)

The following are NOT included and will be handled only under a separate SOW or an approved Change Request:

- Native mobile applications (iOS / Android).
- Content creation, data entry, or migration of legacy records beyond [N] sample records.
- Ongoing maintenance, support, or hosting after the acceptance date (see optional Support section).
- Any feature not explicitly listed in Section 2.1.

---

## 3. Deliverables and acceptance criteria

| # | Deliverable | Acceptance criteria | Format |
|---|-------------|---------------------|--------|
| 1 | [Deliverable] | [Objective, testable condition] | [e.g. deployed URL, repo, doc] |
| 2 | [Deliverable] | [Objective, testable condition] | [Format] |
| 3 | [Deliverable] | [Objective, testable condition] | [Format] |

**Acceptance process:** Client has [5] business days after delivery of each milestone to review and either accept in writing or submit a written list of specific, reproducible defects measured against the acceptance criteria above. Items not raised within the review window are deemed accepted. Silence past the review window is deemed acceptance.

---

## 4. Timeline and milestones

| Milestone | Target date | Payment trigger |
|-----------|-------------|-----------------|
| Kickoff and discovery complete | [Date] | Deposit |
| Milestone 1 delivered | [Date] | [%] |
| Milestone 2 delivered | [Date] | [%] |
| Final acceptance | [Date] | Balance |

Dates assume Client meets the responsibilities in Section 7. Client-caused delays shift dependent dates day for day.

---

## 5. Fees and payment schedule

**Total fixed fee:** [Currency + amount] for the scope in Section 2.1.

Payment schedule:

- **Deposit:** [%] due on signing. Work begins on cleared payment.
- **Progress payments:** as tied to the milestones in Section 4.
- **Final payment:** [%] due within [10] days of final acceptance.

Invoices are due net [10] days. Late amounts accrue interest at [1.5%] per month or the maximum allowed by law, whichever is lower. Fees are exclusive of taxes.

---

## 6. Assumptions

- Client provides timely access to systems, accounts, brand assets, and a single decision-maker.
- Third-party services (hosting, payment, email, model providers) are billed to Client or passed through at cost.
- Scope in Section 2.1 is complete and stable; new requirements go through Section 8.

---

## 7. Client responsibilities

- Name one authorized point of contact empowered to approve deliverables and Change Requests.
- Respond to questions and review requests within [3] business days.
- Provide content, credentials, and test data required to complete the work.

---

## 8. Change control

Any change to scope, deliverables, timeline, or fees must be documented in a written Change Request signed by both parties before the changed work begins. Each Change Request states its impact on scope, schedule, and price.

This SOW includes **[2] rounds of revisions per deliverable** against the acceptance criteria in Section 3. Revision requests beyond the capped rounds, or requests that fall outside the accepted criteria, are billed at [Currency + rate] per hour or quoted as a Change Request.

---

## 9. Intellectual property and source code

On receipt of final payment in full, Agency assigns to Client all right, title, and interest in the custom deliverables and source code created specifically for Client under this SOW. Until final payment is received, all work product remains the property of Agency.

Agency retains ownership of its pre-existing tools, libraries, and know-how, and grants Client a perpetual, non-exclusive license to use those components as embedded in the deliverables. Open-source components remain under their respective licenses.

---

## 10. Hosting and data residency

- **Hosting:** [Provider and region, e.g. deployed to Client's own cloud account, region us-east].
- **Data residency:** Production data is stored in [region]. Agency will not move production data outside [region] without written approval.
- **Access:** Agency access to production systems ends at final acceptance unless a Support agreement is in place.

---

## Optional AI-native clauses

Include the clauses below when the build uses AI models, code-generation platforms, or generated output.

### A. Name the builder platform

The application is built on **[named platform / framework / model provider]**. Client acknowledges the choice of platform and its published pricing, rate limits, and terms. A change of builder platform after signing is a Change Request under Section 8.

### B. Model and provider deprecation

AI model providers may deprecate, rename, or change the pricing of models with limited notice. If a model used in the deliverables is deprecated by its provider, migrating to a replacement model, and any re-testing it requires, is handled as a Change Request. Agency is not liable for provider-driven deprecation outside its control.

### C. Capped prompt and evaluation rounds

The fixed fee includes **[3] rounds of prompt tuning and evaluation** per AI feature, measured against the agreed evaluation set in Section 3. Additional tuning or expansion of the evaluation set beyond the capped rounds is billed as a Change Request. AI output is probabilistic; acceptance is measured against the agreed evaluation set, not against a standard of perfect or identical output on every run.

---

## Signatures

**Client**

Signature: ________________________  Name: [Name]  Title: [Title]  Date: __________

**Agency**

Signature: ________________________  Name: [Name]  Title: [Title]  Date: __________
