Fixed price vs time and materials: which fits AI work?

01Fixed price vs time and materials: what each model buys you

The contract type is a decision about who carries scope risk. It is not a statement about trust or quality. This is part of our larger guide, What is forward deployed engineering?.

The Agile Manifesto values customer collaboration over contract negotiation and responding to change over following a plan. That is sometimes read as an argument against fixed price. It is not. It is an argument against pretending that unknown scope is known. When scope genuinely is known, a fixed price is the most honest contract there is, because both sides can see exactly what done means.

02Why AI makes the choice harder

AI features carry uncertainty that ordinary features do not. Answer quality depends on data nobody has looked at closely yet. Model behavior varies between runs. Success criteria are often vague at the start, such as an assistant that answers customer questions well. Teams respond in one of two ways: they refuse fixed price for anything involving AI, or they fix a price on a vague promise. Both go wrong.

The fix is to separate the parts. Integration work, meaning APIs, connectors and a hook into the user interface, is ordinary engineering and can be fixed. Quality work, meaning how good the answers are, needs either a measurable target on a defined test set or a separate, time-boxed phase. Mixing the two in one fixed price is where most disputes start. Cost is a separate question again: see how much production AI costs in SaaS.

03How to shrink a first AI feature until it fits a fixed price

The most reliable way to make a first AI feature fixable is to make it small and to fence it off from everything that already works. We use six steps:

1. 01

   Find the extension point. Most mature products already have one

   a plugin model, a webhook, a filter pipeline, an API gateway, an embed slot. Build behind it.

2. 02

   Put the platform off limits. Write down that the host application will not be modified. This one sentence removes the largest source of surprise in the whole project.

3. 03

   Make the AI a separate service with a narrow contract

   one request shape, one response shape, versioned so either side can change without breaking the other.

4. 04

   Define failure behavior. Decide what happens when the AI service is slow or down. Failing safe, so the product keeps working without the AI, should be the default.

5. 05

   Write acceptance checks a reviewer can run, for example

   given these documents and these questions, every answer shows its sources, and when the answer is not in the documents the assistant says so.

6. 06

   List what is out of scope, in writing, including the things everyone quietly assumes will come next.

Anthropic's guidance on building with language models recommends starting with the simplest solution that works and adding complexity only when it is needed. That advice is technical, but it is also commercial. The simplest version is the one you can price.

04Buy certainty before you buy the build

When a feature is larger than one service, a short paid scoping phase is often the cheapest way to make a fixed price possible. The output is not a slide deck. It is the material a fixed quote needs: a feature breakdown, wireframes for every role, user stories and a system flow. It also includes a written answer to the hardest integration question, such as how the AI will reach the production database. Once both sides have signed off on that, the build can be fixed with a straight face.

The build itself then runs on a short, visible rhythm: two-week sprints, weekly client meetings, and an internal check of every release against the agreed user stories before the client sees it. That rhythm is what keeps a fixed price fair to both sides, because gaps are found early, while they are still small.

05When fixed price stops being honest

Some projects outgrow their contract, and pretending otherwise hurts both sides. The signs are easy to spot once you look for them. Requirements arrive as users see working builds, approval flows need repeated rework, dashboards go through several iterations, and imported data turns out to be incomplete. None of this is failure. It is what happens when people start using a real system.

The right response is to keep delivering on a regular rhythm and to say what is happening, in writing. Compare the original milestone plan with the change requests, show both side by side, and propose a model that fits the work as it now is. Usually that means time and materials, or fixed phases with priced change requests.

06What we see in production

For a software services firm, we added document search to a self-hosted chat interface on a fixed price scope. The boundary was explicit: one retrieval service built on LlamaIndex, and one thin filter inside the chat platform's existing pipeline model, with the platform itself off limits. The filter takes the user's latest question, fetches the top five chunks, injects them just before the question and shows each source with a relevance score. It accepts both the new and the legacy response format, so the service could change without breaking the interface, and it fails safe: if the service errors, the chat simply continues without context. The contract completed, and the client described our team as persistent and focused.

That fixed boundary came out of scoping calls before any work began, including the client's request to leave the platform's built in retrieval unused. Our technical lead still sent the service back for revisions before the filter reached version 2.2. The contract closed with a 5 star review.

For a retail sales services company, we ran a paid scoping and UI/UX phase before a fixed price build of a multi-tenant AI sales assistant. The phase covered a proposal and feature breakdown, wireframes for all four roles walked through with the client, designs, user stories, a system flow chart and a dedicated session on database connectivity. The build then ran in two-week sprints with weekly meetings, our business analyst evaluated every deployment against the user stories, and every item in the MVP scope was delivered.

For a self-serve ad builder for vehicle dealers, built for a U.S. dealership marketing agency, we started with a narrow fixed price proof that ads could be created from a client-facing site and pushed through the ad platform's API. We then built the interface on a second contract and continued the product on an hourly basis once the shape of the work was clear.

For a large public security organization, we built an on-premise operations system where requirements changed heavily as staff used it, with ten major change requests across approvals, linkage between modules, dashboards and reports. We kept showing working builds on a regular rhythm. We documented the growth openly in progress presentations that compared the original milestones with the change requests, and recommended moving to time and materials or change requests.

Frequently asked questions