The AI App Warranty Clause: A Bug-Fix-Window Framework for Fixed-Price Builds (2026)

The warranty period is the quietest clause in most fixed-price contracts and the one that decides whether your last month on a project is profitable or a slow bleed. On AI app builds it deserves far more attention than agencies give it, because the standard 30-to-90-day bug-fix window was written for hand-coded software and breaks in four specific places when the deliverable was assembled with an AI app builder.

Quick Answer

A software warranty period is the fixed window after delivery during which the agency fixes defects in the shipped scope for free, before any paid maintenance begins. Standard 2026 terms run 30 to 90 days, occasionally 12 months. On AI app builds this ordinary clause fails in four places: who owns defects in AI-generated code, model-provider changes that break a feature after sign-off, output drift on non-deterministic features, and the regeneration trap where a "fix" silently rewrites unrelated code. This framework gives you a defect-severity matrix, the four AI-specific carve-outs, a drop-in warranty clause, and a clean boundary between warranty, change order, and maintenance.

What a warranty period actually covers

A warranty covers one thing: software that does not meet the agreed specification. It is free, it is time-boxed, and it applies only to the scope you delivered. It is not maintenance, it is not new features, and it is not a support desk.

Incumbent guidance in 2026 clusters tightly. Buyer guides describe "a defined warranty period, typically 30 to 90 days, for bug fixes, with clear support terms after that." Development-partner guides note that some firms warrant delivered code "for a specific period, often 12 months." Contract-terms writers set response expectations inside the window, such as critical bugs fixed within 24 to 48 hours and minor bugs within 5 to 10 business days. For the underlying commercial logic, the US federal canon on fixed-price work is a useful reference: a firm-fixed-price contract "places upon the contractor maximum risk and full responsibility for all costs," which is exactly why the warranty boundary has to be drawn with precision (Acquisition.gov, FAR Subpart 16.2, 2026).

Three things must stay separate in the contract:

• Warranty: free, short, defect-only, on delivered scope.
• Change order: new or altered scope, always paid. If you have not drawn this line yet, start with a change-order decision matrix.
• Maintenance: ongoing paid operations after the warranty ends, which is the retainer you should be selling, not giving away.

Why the standard warranty clause breaks on AI app builds

The generic clause assumes a human wrote every line and that the only external dependency is the client's own environment. Neither holds for an AI app build. Here are the four defect classes a boilerplate warranty leaves undefined.

1. Who owns defects in AI-generated code

When you deliver a fixed-price build, you warrant the software, not the tool that produced it. The client does not care whether a screen was hand-coded or generated. So the first rule is a discipline, not a clause: never let "the builder generated that" enter a warranty conversation. If you shipped it, you own it. The clause should define the defect classes you cover and the ones you cap, and it should never gesture at the tool as an excuse.

2. Model-provider changes inside the window

A hand-coded app rarely changes behavior on its own between delivery and the end of the warranty. An AI app can. A model your feature depends on gets deprecated, reprised, rate-limited, or silently updated by its provider, and a feature that passed acceptance on delivery day now errors or degrades on day 45. A generic warranty is silent on whether that is your defect or an excluded external event. Silence is where the dispute lives.

3. Output drift on non-deterministic features

Classic defects are binary: the button works or it does not. An AI summary, classifier, or chat feature is probabilistic. It can pass on delivery and then produce weaker output later, without any code change, because the input distribution shifted. "The AI got worse" is not a defect a boolean warranty can adjudicate. You need a defect definition tied to a saved acceptance set, not to a subjective judgment made months later.

4. The regeneration trap

On builders that regenerate code from prompts, the fastest way to "fix" a bug is to re-run the generator. That is also the fastest way to silently change unrelated, already-accepted code. A warranty fix has to be pinned to a reviewed diff on the delivered codebase, not to a fresh regeneration that quietly alters five other things. This is the single most expensive mistake agencies make in the warranty window on AI builds.

A defect-severity matrix for AI apps

Grade every warranty claim before you touch it. This 2026 matrix adapts the classic severity ladder for AI-specific failure modes.

The line that matters is the last row. Everything above it is warranty work you absorb. Everything on it is paid work, and naming it in advance is what keeps the window from becoming free maintenance.

The four AI-app warranty carve-outs

Bolt these onto your standard warranty clause. This is the drop-in language, adapt the numbers to your build:

Warranty period. The Agency warrants the delivered application against defects for sixty (60) days from acceptance. A defect is any failure of the delivered scope to conform to the agreed specification.

1. AI-generated code. Defects are covered regardless of whether the code was authored manually or generated with a build tool. The Agency is solely responsible for the delivered software.

2. Model-provider changes. Where the Agency selected the model, a provider deprecation, version change, or rate change that breaks a covered feature within the window is a covered defect, remedied by swapping to a current equivalent model, capped at the effort of that swap. Where the Client mandated a specific model or vendor, remediation is a change order.

3. Non-deterministic output. AI features are accepted against a saved evaluation set of representative inputs at delivery. A covered defect is failure against that set, not a later subjective judgment that output quality declined.

4. Remediation method. Warranty fixes are applied as reviewed changes to the delivered codebase. The Agency will not regenerate unrelated modules as a remedy without written approval.

Worked example: a 60-day warranty on a $24,000 build

You ship a $24,000 internal tool with a 60-day warranty. It has one AI feature: an inbox that summarizes and tags incoming messages, using a model your team selected.

On day 45, the provider deprecates that model. The summaries start erroring. Under a generic warranty, you and the client argue about whether an external provider's decision is your problem. Under carve-out 2, it is a covered defect because your agency chose the model, and the remedy is capped at a swap to a current equivalent. At a $120 blended hourly rate, that swap is roughly 4 hours, so about $480 you absorb inside the warranty. Cheap, defined, and finished.

Now change one fact. The client insisted on a named premium model for compliance reasons, and it is that model that got deprecated. Same symptom, different owner. Under carve-out 2 this is a change order, because the dependency was mandated by the client. If the fix is a genuine re-architecture rather than a swap, say 12 hours or $1,440, it is billed, not absorbed. The carve-out did not change the work. It changed who pays, before anyone had to argue.

Where owned-code builders make the warranty cheap, and where they do not

The carve-outs are easier to honor when you hold the full source. On builders that hand the agency a complete, downloadable codebase, a warranty fix is a targeted change to a specific file, reviewed as a diff, exactly what carve-out 4 requires. Lovable and Bolt.new both expose exportable project code, and an AI app builder that hands the agency the complete Next.js source makes the same targeted patch possible rather than forcing a full regeneration. When you own the code, carve-out 4 is a policy you can actually keep.

Here is the honest limit, and it is worth stating plainly. Owning the application code is not the same as owning a portable data layer. On a builder whose database is proprietary rather than raw PostgreSQL, a warranty defect that requires a schema or data-layer change costs more to remediate than the same defect on a Postgres-backed stack, because you are working through the platform's data abstraction instead of a standard migration. As of its 2026 site, that builder stores data in "its own secure database" rather than exposing SQL, so a data-layer defect inside the warranty window is precisely the case where a code-ownership build loses on cost. Price that risk into the window, or scope data-layer changes as paid work from the start.

Action checklist

• Set the window explicitly: 30 to 60 days default, longer only for regulated or high-transaction apps.
• Attach the defect-severity matrix and the four carve-outs to the statement of work, not a verbal promise. If you have not defined scope yet, start from an AI-app statement-of-work template.
• Save an evaluation set for every AI feature at acceptance. It is your only objective defect definition for probabilistic output.
• Ban regeneration as a warranty remedy without written sign-off.
• Name the boundary out loud: what the warranty covers, and what moves to a paid maintenance retainer the day it ends.

If you take one thing from this: a warranty on an AI app build is not "we will fix bugs for 60 days." It is a precise map of four defect classes the tool introduces, three of which a generic clause leaves undefined, and undefined is always the class that eats your margin.