CyberFreezeDev Loading
  1. Home
  2. Blog
  3. How-to guides
  4. Fixed price vs time and materials for AI projects

How-to guides

Fixed price vs time and materials for AI projects

Fixed price suits work you can specify up front and time and materials suits work you learn as you go. AI projects contain both, so a hybrid with a fixed price pilot and an evaluation set as the acceptance test usually serves the buyer best.

Two people at a wooden table going through printed papers
Two people at a wooden table going through printed papers

Fixed price suits work whose result you can specify before it starts; time and materials suits work where you will learn as you go. An AI project contains both kinds, so the contract model that usually serves the buyer best is a hybrid: a fixed price discovery and pilot to remove the biggest unknowns, then fixed price milestones for the build, with acceptance tied to an evaluation set and a pass mark agreed in advance.

A man drawing a flowchart on a large whiteboard
Discovery and a pilot turn the unknowns in an AI project into items you can price.

Fixed price vs time and materials: the trade-off

Fixed price Time and materials
What you agree A defined scope for a set fee A rate and a way of tracking hours
Who carries overrun risk The developer, which prices it in You
Changes Need a change request and a new price Absorbed, at more cost
Suits Work you can specify fully Exploration, tuning, support
Main risk Padding, or arguments about scope A budget with no end

Neither is better in general. A fixed price on a vague scope is not certainty: the developer either adds a large contingency or reopens the price later. Time and materials with no cap and no checkpoints leaves you funding a search with no end date.

Why AI projects have uncertain parts

Most software can be specified before it is built: a form, a report, an integration with a documented API. AI features add two unknowns that nobody can settle from a sales call.

  • Data quality. Until someone opens the files, nobody knows how many invoices are scanned sideways, how many records lack a field, or whether three teams label the same thing three ways.
  • Model accuracy on your cases. Public benchmarks say little about whether a model reads your suppliers' invoices or answers your customers' questions correctly. Only a test on your own examples tells you; that is what model evaluation means.

Two smaller ones follow: the running cost per case, which depends on which model passes, and the edge cases that only turn up in real traffic. These are the parts a fixed price for the whole system would have to guess at.

A hybrid that works

  1. Fixed price discovery. Map the process, look at sample data and agree what success means. The GOV.UK Service Manual's rule for discovery is a good one here: "You should not start building your service in discovery." For a small business this can be a few conversations and a short written plan, which is how our AI strategy consulting runs.
  2. Fixed price pilot. One process, real data, a frozen evaluation set and a pass mark. GOV.UK's alpha phase is the model: test the riskiest assumptions and expect to throw code away. The evaluation set is the part you keep.
  3. Fixed price milestones for the build. Once the pilot passes, the remaining unknowns are small enough to price. Each milestone ends with a demo on staging and a written record, and you can stop or change direction between them.
  4. Time and materials, capped, for what stays open. Prompt tuning for new edge cases, small changes after launch and support fit a monthly cap better than a fixed scope.

This is the structure we suggest for custom AI systems: the fixed price parts cover what is known, and the open parts have a ceiling.

A hand writing on printed pages next to a notebook and a coffee mug
An evaluation set with a pass mark gives both sides the same test for when an AI feature is done.

What to write into acceptance criteria for an AI feature

"The chatbot answers accurately" cannot be accepted or rejected. Anthropic's guidance on evaluations asks for criteria that are specific, measurable, achievable and relevant, and notes that most uses need several criteria, not one. In a contract that means:

  • The evaluation set. Who supplies it, how many cases (50 to a few hundred real ones is typical), and that it is frozen before the build starts. Include the messy and rare cases.
  • A held-out part. Keep some cases back from the developer so the final score is not on examples the system was tuned to.
  • How each case is scored. Exact match for extracted fields and labels; a checklist, a reviewer or a separate model as judge for open text.
  • The pass mark, per criterion: accuracy, plus what happens when the system is unsure, response time and cost per case.
  • What happens on a miss. A fix period, a rerun, and the right to stop.

An illustrative clause, with numbers you would set yourself:

The feature is accepted when, on the agreed 200 case evaluation set, it extracts the invoice total exactly in at least 95 percent of cases, sends every case below the confidence threshold to the review queue, and returns each result within 10 seconds. The set is rerun on every change of model or prompt, and the results are shared with the client.

Contract terms for a US or UK buyer

Currency, payment schedule and governing law are agreed in the written proposal before work starts. Tie payments to milestones that end in a demo, not to dates. If you are in the US, the overnight cycle described on our United States page suits milestone reviews well: you test on staging in your morning, and changes are made while you sleep.

Talk it through

Bring the process you want to automate, and we will propose a discovery, a pilot with a pass mark, and the milestones after it. Book a consultation.