Fixed price vs time and materials vs retainer: how to pay for an AI project

Every AI proposal arrives with a pricing model attached, and the model decides who pays when something goes wrong. A fixed price protects a buyer from overruns but can punish change. Hourly billing protects flexibility but can drift. A retainer smooths cost but pays for capacity rather than results. This guide is for operations, finance and IT leads at companies of roughly 20 to 200 people who need to compare quotes, pick a structure for each phase of an AI project and write the protections into the contract.

Fixed price vs time and materials vs retainer: how do they compare?

Choose a fixed price for settled scope, time and materials for uncertain scope and a retainer for ongoing support, and expect to use more than one across a project. The table shows what each model means for the buyer, and the sections below explain each row.

The short verdict: a fixed price is only as good as the scope behind it, time and materials is only as safe as the cap and reporting around it, and a retainer is only worth paying for if you can name what it will be used for.

What are the advantages and disadvantages of each pricing model?

Each model answers one question, what exactly the buyer is paying for, and each has one main strength and one main weakness for the buyer.

• Fixed price is an agreed total for an agreed scope. The US Federal Acquisition Regulation, which governs public procurement and works as a neutral definition, describes a firm-fixed-price contract as one with a price not subject to adjustment based on the contractor's cost experience.
• Time and materials bills hours at agreed rates plus materials. The FAR rules allow it only when it is not possible at the outset to estimate accurately the extent or duration of the work.
• Milestone-based fixed fee divides a fixed price into stages, each with its own deliverable, acceptance test and payment.
• Retainer is a recurring monthly fee for a defined block of time or service, usually for support after launch.

The FAR is direct about the incentive problem with hourly billing: it provides no positive profit incentive to the contractor for cost control or labor efficiency, so the buyer needs oversight. That is why caps and weekly reports matter.

Which pricing model fits an AI audit, a build and ongoing support?

Match the pricing model to how much is known at each phase of the project, not to a single preference for the whole engagement.

AI work has more discovery risk than ordinary software because the answer depends on your data. Whether an invoice reader works at an acceptable accuracy cannot be known until it is tested on your real invoices. That is why a defined audit or pilot, priced separately, often comes before any fixed-price build. Our guide to what drives the cost of an AI readiness audit explains why audits are scoped rather than list-priced.

How does risk shift between buyer and vendor, and who pays for change?

A pricing model does not remove risk. It moves risk to the party that agrees to carry it, and that party will charge for it or manage it in other ways.

Under a fixed price, the vendor carries overrun risk, so it protects itself with contingency, a long assumptions list and tight limits on change. The buyer carries the risk that the written scope is wrong: if the contract describes the wrong workflow, the vendor delivers exactly that, and the fix is a paid change order.

Under time and materials, the buyer carries the cost risk. The protections are the ones you write in: a cap the vendor exceeds at its own risk (which the FAR itself requires for hourly contracts), regular reporting and the right to stop. A change is a reprioritization inside the cap, which fits the Agile Manifesto preference for customer collaboration over contract negotiation.

Under a retainer, the risk is waste. The vendor is paid whether or not you use the time, so the buyer needs a backlog of requests that justifies the fee.

Put risk with the party best able to control it. The vendor controls efficiency, so some efficiency risk belongs with the vendor. The buyer controls decisions, data access and feedback speed, so some schedule risk belongs with the buyer. Four rules keep scope creep under control in any model:

1. Write down what is out of scope, not just what is in scope.
2. Name one person on the buyer side who can approve changes.
3. Require a written estimate of cost and schedule impact before changed work starts.
4. Review a log of accepted and rejected changes at every milestone.

How do milestone-based fixed fees work?

A milestone-based fixed fee divides one fixed price into stages, and each stage is paid only after the buyer accepts a defined deliverable against a written test. It is the structure that most often balances the buyer's need for control with the vendor's need for clear scope.

A workable milestone has four parts: a deliverable you can inspect, an acceptance test with a pass mark, a date and a payment tied to acceptance. For an AI workflow, typical milestones include:

1. Design and data access confirmed. The workflow map, the systems to connect, the permissions granted and a test set of real past cases.
2. Working prototype on the test set. The system runs against the agreed cases, and results are reported by type of error.
3. Integrated version in a staging environment. The workflow connects to the real systems with approval steps in place, and users try it.
4. Production release and handover. Training, documentation, monitoring and transfer of code and accounts.

Illustrative example: Consider a 90-person distributor that wants an AI workflow to check supplier invoices against purchase orders and route exceptions to a person for approval. The buyer starts with a short, fixed-scope audit, which produces a process map, a list of systems and a test set of past invoices with the correct outcome for each. The build is then quoted as four milestones. Each milestone has a pass mark written in advance, such as the share of test invoices handled correctly and the share of exceptions routed to the right person. Payment follows acceptance, and a change to the approval rules is priced as a change order. After launch, support moves to a monthly retainer with a review every quarter.

How do you compare quotes that use different pricing models?

Quotes in different models cannot be compared by their headline number, so first force them onto the same scope, then test each against the same scenarios. Use this sequence:

1. Write one scope. Give every vendor the same brief, with systems, users, volumes and the definition of success. Our guides to writing an RFP for an AI implementation project and choosing an AI implementation partner cover how to run that process fairly.
2. Ask fixed-price vendors for assumptions and exclusions. An assumption that your data is clean or your systems have working APIs is a risk the buyer silently keeps.
3. Ask time-and-materials vendors for an estimate range, a cap and the rate card. A vendor unwilling to estimate or cap has priced nothing yet.
4. Check what is included after launch. Hosting, monitoring, bug fixes and support are often excluded from the build price.
5. Run the three scenarios below on every quote.

If a quote does not say what happens in each row, ask before you sign.

What should the contract say about acceptance, change control and ownership?

The contract should define done, control change and settle ownership, whichever pricing model you choose. Use this checklist when you review a draft:

1. Acceptance criteria. For each deliverable, a written test with pass marks, who runs it, on what data and how long you have to accept or reject. Agree what correct means for each task in advance.
2. Change control. Who can request a change, who can approve it, the form of the estimate and a rule that no changed work is billable without written approval.
3. Cap and reporting for hourly work. A not-to-exceed total, a weekly summary of hours by task and the right to stop at any milestone.
4. Payment schedule. Payments tied to acceptance, not to elapsed time, and a holdback until handover is complete.
5. Intellectual property. An explicit assignment of the code, prompts, configuration and documentation to you. The US Copyright Office explains that commissioned work counts as work made for hire only when it falls in specific listed categories and the parties sign a written agreement saying so, so a clear written assignment is safer than assuming ownership. Ask your counsel to confirm the wording.
6. Data and accounts. Repositories, cloud accounts and model provider accounts in your name, and a clear statement of how your data may be used.
7. Handover. Documentation detailed enough for another team to take over, plus a walkthrough.
8. Warranty, support and termination. A period of free defect fixes, the terms of any retainer including unused hours, and the right to end at a milestone with ownership of all work to date.

How Kastling approaches pricing structure for AI projects

Kastling is an AI solutions and implementation partner, and it separates the stages of an engagement so that each can be scoped and agreed on its own. An engagement starts with a free discovery call to understand the problem and the fit. For AI and operations work, a separately scoped, paid audit usually follows, although a clearly defined software brief can move straight to a scoped proposal.

The proposal sets out the recommended solution, scope, milestones, dependencies and the measures of success before development begins. Development is tested against real business scenarios, then integrated with training. Ongoing maintenance is optional and sits under a separate agreement that states what it covers and how it is billed.

Kastling does not publish a price list, because cost depends on scope. AI Integration & Automation describes the work, and a discovery call is the place to talk through which structure suits your project.