Cross-Industry & Business Teams

Fixed Price vs Time and Materials: Which to Sign for AI Work?

Fixed price vs time and materials for an AI project? See why hourly billing is breaking, why outcome pricing fails, and what a safe AI contract contains.

October 22, 202613 min read
Hand-drawn balance scale weighing an hourglass against a sealed contract, illustrating fixed price vs time and materials for AI projects

What matters most

  • Time and materials suits only short, capped discovery work on AI projects, because AI tools make hours a poor measure of value.
  • A fixed price against written acceptance tests on your own documents is the safest default for an AI build.
  • Outcome-based pricing works only for units the system controls, such as documents processed at an agreed accuracy.
  • About 60% of Accenture's work is now fixed price, up roughly 10 points in three years, according to UpperEdge.
  • Every AI system needs a separate monthly run-and-fix agreement, because document formats, models and systems change after launch.

You have three proposals on the table for the same AI project. The first says time and materials, estimated at 400 hours. The second says fixed price, one number, delivered in eight weeks. The third, from the vendor who talked the most about "partnership," offers to take a share of the savings instead of a fee. Your CFO wants to know which one is safest. Your operations lead wants to know which one will actually get finished.

I run engineering at Chronexa, and I sit on the other side of this table every week. Here is my honest answer to the fixed price vs time and materials question for AI work, including the parts vendors usually leave out.

Here's what matters most:

  • Hourly billing for AI work is breaking. AI tools cut the hours it takes to build, and large service firms are already moving away from billing by the hour.
  • Fixed price against a written specification is the right default for most AI projects where you know which documents, systems and people are involved.
  • Time and materials is right for discovery, when nobody yet knows what your data looks like. Cap it and keep it short.
  • Pure outcome-based pricing rarely works for AI projects, because the vendor cannot control the business decisions that produce the outcome.
  • Budget a separate monthly fee to run and fix the system. AI systems drift after launch, and someone has to own that.

What is the difference between fixed price and time and materials?

A time and materials contract (usually shortened to T&M) bills you for hours worked at an agreed rate, plus any costs the vendor passes through. You pay for effort. If the work takes longer, you pay more. If it goes faster, you pay less, at least in theory.

A fixed price contract sets one price for a defined scope. You pay for a result described in writing. If the work takes longer, the vendor absorbs the cost. If it goes faster, the vendor keeps the difference.

An outcome-based contract ties the fee to a business result: a share of cost savings, a payment per booked meeting, a percentage of recovered revenue. You pay only if the result shows up.

Every buying guide on page one of Google explains these three models in the abstract, mostly for construction projects or custom software. None of them deal with the thing that makes AI work different: the vendor's own tools are cutting the hours, and the result depends on your business as much as on their code. That changes which model protects you.

Why is hourly billing breaking for AI projects?

The short version: when AI writes a large share of the code and drafts a large share of the documents, the hours collapse, and an hourly contract becomes a strange thing to sign.

The biggest service firms are saying this openly. In earnings calls covered by Zerodha's Daily Brief in May 2026, HCLTech's chief executive C. Vijayakumar said that 40% of the IT services industry "runs the risk of being disrupted by AI and can shrink 3% to 5% CAGR for a few years." He estimated that a $100 million deal under the old model would now close at "maybe 80 million, just on a rough ballpark." He had already told clients that using HCLTech's own AI tools would "mean some reduction in revenue for us. And we are okay with that."

Infosys's chief financial officer, Jayesh Sanghrajka, said on the same round of calls that competition has increased and productivity gains will largely be passed back to clients.

Meanwhile the contracts are changing shape. UpperEdge, an advisory firm that negotiates with systems integrators on behalf of buyers, reported in August 2026 that "approximately 60% of [Accenture's] work is now fixed price, up roughly 10 percentage points over the last three years." Its author made a point every buyer should read twice: the shift "isn't being driven by clients, it's being driven by the SIs themselves." Under time and materials, the client can see exactly how few hours the same scope now takes. Under fixed price, the vendor keeps the productivity gain.

That is the part nobody puts in the proposal. A fixed price is not automatically a gift to you. If the vendor's AI tools cut their effort in half and the price was set on last year's effort, the saving goes to them. So the question is not only which model, but which model at what number, against what written scope.

My own view after building these systems: the hours were always a poor proxy for value, and AI has made them a misleading one. What you are really buying is three things. The knowledge of what to build. The work of connecting your messy systems and data. And someone who stays accountable when the system breaks in month four. None of those are measured well in hours.

Why does outcome-based pricing usually fail for AI projects?

Outcome-based pricing sounds like the safest choice for a buyer. You only pay if it works. In my experience it is the model most likely to end in a dispute, and the reason is simple: an AI system produces an output, but your business produces the outcome.

Here is an example from our own work. At Chronexa we built an outbound sales engine for ourselves: it researched prospects, wrote personalized emails and followed up for days. The engine did exactly what it was built to do. The results came from strategy. When the system wrote a different pitch for every lead, we got one reply in roughly 560 sends. A later campaign with a fixed offer reached 895 emails with zero replies. The software was identical in both cases. What changed was the offer, the audience and the angle, which are decisions a business makes, not a vendor.

If we had been an outside vendor paid per booked meeting, we would have lost money on a system that worked perfectly. If we had been the client, we would have argued that the system was broken. Both sides would have been partly right, and nobody could have proved it.

That is the trap. Outcomes like revenue, meetings, retention or "savings" depend on your offer, your pricing, your people and your market. A vendor cannot control those, so a vendor who accepts outcome pricing either inflates the price to cover the risk, quietly narrows what counts as an outcome, or walks away when the numbers disappoint.

There is one form of outcome pricing that does work: pricing on the system's own output, not on the business result. For example:

  • a price per document processed, with an agreed accuracy threshold measured on a sample;
  • a price per invoice matched and posted, where exceptions go to your team;
  • a price per call handled by an AI receptionist, with a defined rule for when it transfers to a person.

Those are units the vendor actually controls. The business outcome that follows (faster cash collection, fewer missed calls) is still yours to manage, but nobody is arguing about whether the machine did its job.

When should you choose fixed price, and when time and materials?

Most AI projects should be split into stages, and each stage gets a different pricing model. This is the structure I recommend to buyers, and the one I would sign myself.

Stage 1: paid discovery, time and materials, hard cap. Before anyone can quote a fair fixed price, someone has to look at your real documents, your real systems and the exceptions your team handles by memory. That is genuinely unknown work, so T&M is honest here. Keep it short (one to three weeks is typical) and put a ceiling on the total.

Stage 2: the build, fixed price, against a written specification. Once the inputs are known, the vendor should be able to commit. The specification names the documents, the systems, the steps and the tests the finished system has to pass. If a vendor will not fix a price after a proper discovery stage, that tells you they do not understand your process yet, or they expect the scope to grow.

Stage 3: run and improve, a monthly fee. AI systems are not like a website you launch and forget. Document formats change, a supplier redesigns its invoice, a model provider updates its model, someone adds a new field to your client portal. The system needs watching and fixing. A monthly fee with a clear list of what it covers (monitoring, fixes, small changes, a response time) keeps someone accountable.

Choose time and materials for the whole project only when the work is genuinely open-ended: research, a prototype to test an idea, or a team augmentation arrangement where your own people direct the work day to day.

Choose fixed price for the whole project only when the scope is small and well understood, such as one document type moving through one approval step into one system.

Gartner gave a useful warning on this in June 2025, when it predicted that over 40% of agentic AI projects (projects where the AI takes actions, not just answers questions) will be cancelled by the end of 2027, citing escalating costs, unclear business value and inadequate risk controls. Two of those three reasons are contract problems. A staged structure with a cap on discovery and a fixed build price is the cheapest protection against both.

What should a fixed-price AI contract actually contain?

A fixed price is only as good as the specification behind it. Here is the checklist I would want in any AI contract, whichever side of the table I am on.

1. Acceptance tests on your real material. Not "the system extracts invoice data." Instead: "the system processes the attached 200 sample invoices and reaches at least 97% field-level accuracy, with every low-confidence item sent to the accounts team for review." The numbers should be yours to set. The samples should be your real documents.

2. A list of systems and who provides access, by when. Most AI projects slip because a login, a test account or a data export arrives three weeks late. Put dates on the client's obligations too, and agree what happens to the timeline if they slip.

3. A change rule. New document types, new systems or new steps are changes. Agree in advance how they are priced (a day rate, or a small fixed price per change) so nobody argues later.

4. Who pays for the AI usage. Every AI system has a running cost from the model provider, charged by usage. Decide whether that cost passes through to you at cost, is bundled into the monthly fee, or is capped. Usage costs have a habit of growing faster than anyone expects.

5. Ownership. You should own the workflows, the prompts (the written instructions that tell the AI what to do), the configuration and any code written for you, and be able to run them without the vendor.

6. Where your data lives. For a mid-sized firm this is usually the deciding question. The cleanest answer is that the system runs in your own cloud account (Microsoft Azure, Amazon Web Services or Google Cloud), uses an enterprise agreement with the model provider that excludes training on your data, and keeps an audit trail of every action the AI took and every person who approved it.

7. Exit terms. If you end the monthly agreement, what does the vendor hand over, in what format, and within how many days?

The mid-sized firm's real fear is rarely the price. It is that the new system will not fit the tools the team already uses, or that it will expose client data, or that staff will route around it. Items 2, 6 and 7 in that list exist to answer exactly those fears, in writing, before you sign.

How much should an AI project cost under each model?

Published prices vary widely and most come from vendors, so treat any number as a range, not a quote. Comparison pieces from vendors such as eesel and 11x put a typical mid-market implementation of Salesforce's Agentforce at roughly $50,000 to $150,000 in services, with total first-year cost often landing between $150,000 and $600,000 once licences and usage are included. Those are platform rollouts for larger teams. A focused system that automates one workflow, such as client document intake or invoice matching, usually costs a fraction of that.

We broke down what different budget levels actually buy in our guide to AI automation agency pricing, and the AI automation cost page shows how we scope and price work. The more useful number for your decision is not the vendor's price but your own: what the current process costs you in staff hours, delays and errors. If you have not calculated that yet, the AI ROI calculator takes about two minutes.

One more honest note. A very low fixed price for complex work is a warning sign, not a bargain. It usually means the vendor plans to recover margin through change requests, or has not understood your data. A fair fixed price with a strict change rule beats a cheap one with a vague scope every time.

Frequently Asked Questions

Is fixed price or time and materials better for AI projects?

For most AI projects, a fixed price against a written specification is better once the scope is known, because AI tools make hours an unreliable measure of value. Use time and materials only for a short, capped discovery stage, or for genuinely open-ended research and prototyping.

Why do AI vendors prefer fixed-price contracts now?

Because AI tools cut the effort needed to deliver the same scope, and a fixed price lets the vendor keep that productivity gain. UpperEdge reported in August 2026 that about 60% of Accenture's work is now fixed price, up roughly 10 percentage points in three years, and that the shift is driven by the service firms themselves. Negotiate the number with that in mind.

Should I agree to outcome-based pricing for an AI project?

Only if the outcome is something the system itself controls, such as documents processed at an agreed accuracy, or calls handled under defined rules. Business outcomes like revenue, booked meetings or total savings depend on your strategy and team, so tying fees to them usually leads to inflated prices or disputes.

What should I check before signing a fixed-price AI contract?

Check for acceptance tests run on your own sample documents, dated access obligations on both sides, a pre-agreed change rule, a clear answer on who pays for AI usage costs, your ownership of the workflows and instructions, where your data is stored, and what the vendor hands over if you leave.

The bottom line

Hourly billing made sense when hours were the main thing a vendor sold. For AI work they no longer are. What you are buying is knowledge of your process, the work of connecting your systems, and accountability after launch. So price it that way: a short capped discovery, a fixed build against tests you wrote, and a monthly fee for someone to keep it running. Leave the business outcome where it belongs, with the people who run the business.

If you want a second opinion on a proposal you have already received, book a 30-minute call and we will walk through the scope and the contract terms with you. For more on picking the right partner in the first place, read how to choose an AI automation agency for regulated industries and our comparison of productized automation vs custom development.

Cross-Industry & Business TeamsWhy Are HOA Fees So High, and Will They Keep Going Up?Cross-Industry & Business TeamsWhat Happens If You Don't Pay HOA Fees? The Steps, in OrderCross-Industry & Business TeamsWhat Do HOA Fees Cover, and Where Does Your Money Actually Go?