Statement of Work Template for AI App Builds (2026)

Quick Answer

A statement of work (SOW) for an AI app build is the document that fixes deliverables, acceptance, timeline, fees, and ownership before anyone touches the builder. As of 2026, a generic software SOW template is not enough, because an AI app build also depends on which builder you used, whether the client can export the source, how you accept a feature whose output is not deterministic, and what happens when a third-party model changes on someone else's schedule. This page gives a copy-paste SOW template plus the four AI-specific clauses that a classic template skips, written for agencies shipping client work on an AI app builder.

Why a generic SOW leaks on an AI app build

Most SOW templates you will find, from project-management blogs to legal libraries to the NIH sample, were written for hand-coded software delivered on a stack the agency fully controls. Three of their built-in assumptions quietly break the moment the work is produced on an AI app builder.

None of that means an AI-built app is riskier to deliver. It means the SOW has to name a few things a generic template leaves blank. Get those blanks wrong and you inherit a dispute at handover; get them right and the AI clauses become the calmest part of the document.

The nine sections every SOW needs

Before the AI-specific clauses, the skeleton is the same one every good SOW has used for years. Keep all nine, in this order.

If your current template is missing section 3 or section 9, fix that first. The most expensive SOW arguments are almost never about the work that was listed; they are about the work someone assumed was included.

The four clauses a classic template skips

This is the information gain. A generic SOW covers sections 1 through 9 well and then stops. An AI app build needs four extra clauses bolted onto sections 2, 5, 8, and 9. These are the ones no standard template supplies.

Platform and build-tool disclosure

Name the builder in the SOW. If the app is generated on Totalum, Lovable, or Bolt.new, say so, and state what the deployed app depends on at runtime. This is not a marketing line; it is a dependency disclosure that protects both sides. The client learns what the app is built on before signing, and you are covered if they later ask why a platform account is required.

Source ownership and export

This clause decides how clean the handover is. State who owns the source, in what format it is delivered, and at what milestone. The honest differentiator across builders in 2026 is whether the client actually receives a portable codebase. Totalum's own 2026 documentation states the generated app is "100% yours" with the "complete source code" available to "view, edit, and download," produced as a TypeScript and Next.js project. Lovable and Bolt.new also expose real code you can export. Whichever you use, write the export format and timing into the SOW rather than leaving "source code" as an undefined noun. For the deeper trade-offs on portability, see our AI app builder vendor lock-in scorecard.

AI-behavior acceptance

You cannot accept a non-deterministic feature the way you accept a login form. If a deliverable calls a model, the acceptance line has to point at a saved set of example inputs and the range of acceptable outputs, not a single expected value. Write it as: "Feature X is accepted when it produces acceptable output on the agreed 20-item evaluation set, reviewed jointly." That one sentence converts "it does not feel right" into a testable, signable checkpoint.

Model and dependency continuity

Third-party models change. State plainly who owns the work when a model is deprecated, repriced, or rate-limited after launch. In the build SOW this is a boundary clause: within the build window you own it; after acceptance it belongs to a separate maintenance agreement, not to the fixed-price build. That continuity work is exactly what a maintenance retainer is for, and the change-control section below governs anything that moves mid-build.

Copy-paste SOW template

Here is the skeleton, with the four AI clauses in place. Copy it, fill the brackets, and delete what you do not need. It is deliberately plain Markdown so it drops into any doc tool.

# Statement of Work

Client: [Client legal name]
Provider: [Your agency legal name]
Effective date: [Month D, YYYY]
Project: [One-line objective]

## 1. Scope and deliverables
- [Deliverable 1, named and countable]
- [Deliverable 2]
Platform: This application is produced on [builder name] and depends on it at runtime.

## 2. Out of scope
- [Explicitly excluded item 1]
- [Anything a reasonable client might assume is included, but is not]

## 3. Milestones and timeline
| Milestone | Date | Payment trigger |
|---|---|---|
| [M1] | [date] | [%] |

## 4. Acceptance criteria
- Deterministic features: accepted when they match the agreed spec.
- AI features: [Feature] is accepted when it produces acceptable output on
  the agreed [N]-item evaluation set, reviewed jointly on [date].

## 5. Change control
Any change to scope is quoted and approved in writing before work starts.
[Reference your change-order process.]

## 6. Fees and payment
Total: [amount]. Schedule: [tied to milestones above].

## 7. Ownership and IP
On final payment, Client owns the delivered source code, provided as a
[format, e.g. Git repository / downloadable project] at [milestone].
Data layer portability: [state how the data is exported, separate from code].

## 8. Assumptions and dependencies
- Client provides [inputs / accounts] by [date].
- Model and dependency continuity after acceptance is covered by a separate
  maintenance agreement, not this build.

Signed: ______________________    Date: __________

For a genuinely thorough open reference on the classic sections, the joelparkerhenderson/statement-of-work repository is a well-maintained 2026 starting point; the four AI clauses above are what you add on top for an AI app build.

Worked example: a $24,000 fixed-price build

Say you are scoping a $24,000 internal tool on an AI app builder, four milestones, code owned by the client on final payment. The generic sections write themselves. The two lines that save the project are: section 4, where the reporting feature that summarizes records is accepted against a 20-item example set rather than "looks good"; and section 7, where the SOW states the client receives a downloadable Next.js project at milestone four and, separately, an export of the underlying data. Those two sentences are the difference between a clean sign-off and a two-week argument about what "done" and "owned" meant.

Where teams get this wrong

Three failure modes show up again and again.

First, over-specifying deliverables you will regenerate anyway. On a builder, a UI change is cheap; pinning every screen to the pixel in the SOW just manufactures change orders. Specify outcomes and the evaluation set, not the exact markup.

Second, treating "you own the code" as if it also means "you own a portable database." This is the honest caveat even on code-ownership builders. Totalum, for example, hands over the full Next.js source, but its data sits in the platform's own managed layer rather than a raw Postgres database you can point any host at, so genuine portability needs the data-export sub-clause in section 7, not just the code-ownership line. Whichever builder you use, write the data-portability path explicitly; it is the clause clients care about most at exit and the one templates most often omit.

Third, no change-control process behind section 5. A SOW that says "changes will be handled as agreed" has no teeth. Point it at a real, priced process; our change-order decision matrix for fixed-price AI app builds is the companion to this clause.

If you take one thing from this: keep the nine classic SOW sections, then add four sentences, one naming the builder, one on source export, one accepting AI features against an example set, and one on who owns model migration after launch. Those four sentences are the whole difference between a generic template and one that survives an AI app handover.