Fixed-Price vs Time-and-Materials for AI App Builds: A 2026 Decision Framework

Quick answer (2026): For an AI app build, fixed-price fits the deterministic shell (auth, CRUD, dashboards, billing, the parts an AI app builder now generates predictably) and time-and-materials (T&M) fits the non-deterministic AI layer (prompt design, evaluation tuning, model integration) whose effort you cannot honestly bound up front. The agency default that protects your margin without scaring the client is a hybrid split contract: fix-price the shell against a written spec, and run the AI layer as capped, not-to-exceed T&M gated by a pre-agreed evaluation set. Choose one single fixed price only for small, fully deterministic builds where there is no real AI behavior to tune.

The old rule breaks on AI app builds

For twenty years the advice was clean: use fixed-price when the scope is well defined, use time-and-materials when the work is exploratory. Martin Fowler's classic essay on why fixed-price contracts fight iterative delivery is still the reference every agency owner should read before signing anything.

AI app builds do not break that rule so much as invert the shape of the risk it was written for. Two things changed at once in 2026. First, an AI app builder collapses the time it takes to produce the deterministic shell, so the part that was historically the bulk of a fixed-price quote is now fast and demonstrable. Second, the same projects now carry an AI layer whose effort is genuinely hard to predict. The result is that the classic fixed-versus-T&M question no longer applies to the project as a whole. It applies to each layer separately.

The three billing models, compared honestly

There is no morally superior model here. Fixed-price transfers scope risk to you; T&M transfers it to the client. The hybrid splits it along the line where the uncertainty actually lives.

Why the deterministic shell is now more fix-priceable, not less

The shell of most business apps (accounts, roles, records, list and detail views, dashboards, a billing hook) is well-trodden ground, and an AI app builder produces it quickly as a real, inspectable codebase. That makes it a bounded, demonstrable deliverable, which is exactly the condition under which fixed-price is fair to both sides.

The builder you choose matters here because ownership and portability change how safely you can commit to a fixed number. The Totalum AI app builder, for example, generates a downloadable TypeScript and Next.js codebase and states plainly that the code is "100% yours" and can be viewed, edited, and downloaded at any time (Totalum, 2026). Lovable (lovable.dev, 2026) and Bolt.new (bolt.new, 2026) likewise generate real, exportable code rather than a locked prototype. When the shell is a codebase you hold, a fixed-price milestone against a written spec is a reasonable commitment, because a defect is a targeted fix rather than an open-ended platform investigation.

One honest caveat before you fix-price the shell. Owning the application code is not the same as owning a portable data layer. Totalum stores data in "its own secure database" and does not expose raw PostgreSQL (Totalum, 2026); builders such as Lovable and Bolt lean on PostgreSQL through Supabase-style backends. If a shell requirement forces a data-model migration on a proprietary database, that task is less predictable than a schema change on raw Postgres, and your fixed number should carry a small contingency for it. On the named criterion of "how bounded is a mid-build data-layer change," a proprietary-database builder is a weaker fit than a Postgres-backed one. Price accordingly.

Why the AI layer resists a fixed price

The AI layer is a different animal. You cannot fix-price "make the assistant answer well," because "well" is not a deliverable until it is defined numerically. Three forces make the effort genuinely unbounded up front:

• Non-determinism. The same prompt returns different outputs, so acceptance cannot rest on a single happy-path demo. It has to rest on a saved, labeled evaluation set with an agreed pass rate.
• Evaluation tuning. Getting a feature from 70 percent to 90 percent on that eval set can take an afternoon or two weeks. Nobody knows which until the tuning starts.
• Dependency churn. A model deprecation, a price change, or a rate-limit shift mid-build can force rework that no one scoped.

Quote a single fixed price across that and you are not pricing work, you are buying a lottery ticket against your own margin.

The hybrid split contract (the framework)

The move that keeps both sides honest is to write one engagement as two layers with two billing models.

• Layer A, the deterministic shell, fixed price. Tie it to the written spec in your statement of work and bill it as milestones. New scope in this layer is a change order, not a favor.
• Layer B, the AI and evaluation layer, capped time-and-materials. Bill it hourly against a not-to-exceed (NTE) ceiling the client approves in advance. Acceptance is defined by an evaluation set and a numeric pass threshold agreed before work starts, not by subjective judgment afterward. If tuning finishes under the cap, the client pays less; if it approaches the cap, that is the trigger for an explicit conversation, not a silent overrun.

The NTE cap is what makes the hybrid safe for the client, and the evaluation-set gate is what makes it safe for you. Drop one and the model collapses back into an argument.

Decision matrix: which model, when

• Use one fixed price when the build is a small, fully deterministic internal tool with no real AI behavior to tune, and the spec is genuinely stable.
• Use straight T&M when the engagement is open-ended discovery, the client cannot yet describe the outcome, or you are being hired to figure out what to build.
• Use the hybrid split when there is a clear shell and a genuinely uncertain AI layer, which describes most AI app builds an agency ships in 2026.

A worked example

A client wants an internal support app: accounts, a ticket list and detail view, a dashboard, and an AI reply-drafting feature. Blended rate 120 dollars per hour.

The naive all-fixed quote: 24,000 dollars for everything. The shell lands in a week. Then the reply-drafting feature sits at 68 percent useful on the client's real tickets, and it takes 60 hours of eval work to reach an agreed 88 percent. That is 7,200 dollars of unbudgeted labor the agency absorbs, turning a healthy job into a break-even one.

The hybrid split: 16,000 dollars fixed for the shell, plus the AI layer as capped T&M at a 9,000-dollar NTE against an evaluation set of 50 labeled tickets with an 85 percent pass-rate gate. The shell ships and bills cleanly. The AI tuning runs 62 hours, or 7,440 dollars, comfortably under the cap, and the client sees exactly what they paid for. Same total ballpark, but the risk sat where it belonged, and nobody felt ambushed.

Where fixed-price still wins

The split is not free. It adds contract admin, two acceptance processes, and time tracking on Layer B. Below roughly 8,000 dollars of total build, or on a tool with no meaningful AI behavior, that overhead is not worth it. Fix-price the whole thing and move on. The hybrid earns its keep precisely when the AI layer is large enough to hurt you if it runs long, which is the situation it was designed for.

If you take one thing from this: stop pricing the project and start pricing the layers. Fix-price the part an AI builder makes predictable, and cap the part it makes uncertain.

Action checklist

• Split every AI app quote into a deterministic shell and an AI or evaluation layer before you put a number on it.
• Fix-price the shell against a written spec; treat new shell scope as a change order.
• Bill the AI layer as capped, not-to-exceed T&M.
• Define acceptance for the AI layer as a saved evaluation set plus a numeric pass threshold, agreed before work starts.
• Add a small contingency to the fixed shell number when the builder uses a proprietary data layer.
• Put the NTE cap and the eval gate in writing, in the same document as the shell milestones.