# Fixed Price vs Hourly AI Development: Which Contract to Sign

Pay a fixed price when you can write the finish line as a test. Pay by the hour only for research no one can define yet. Cap it, and give it a stop date. On an hourly bill, the extra hours are yours. On a fixed price, they are the vendor's, if the contract defines done.

*By Cameron Sullivan, Founder & CEO, Techify AI · 15 October 2026 · 9 min read*

> **Key takeaways**
>
> - On an hourly contract (also called time and materials), you pay for every hour past the estimate. Say the rate is $150 an hour. A 400-hour estimate that runs to 600 hours then costs $90,000, not $60,000.
> - The US government's buying rules say it plainly. A time-and-materials contract "provides no positive profit incentive to the contractor for cost control or labor efficiency." A firm fixed price puts the cost risk on the contractor.
> - Hourly fits research, where no one can yet say what good looks like. Cap it in dollars. Give it a stop date. And make what you get at the end a written answer.
> - A fixed price holds only if the scope has seven parts. Deliverables, architecture, phases and dates come first. Then win conditions, what the vendor needs from you, and one price.
> - Acceptance criteria are the tests a build must pass. Freeze the test set before the build. A good one: 190 of the 200 questions in Appendix B answered correctly, with the source named.

Pick by one question. Can you write down what finished looks like? Maybe you can name each thing you will get. You know the systems it plugs into. You can write a pass or fail test for each one. Then buy the build at a fixed price, paid and accepted one phase at a time.

Now say the honest answer is "we don't know yet." Can a model read these files at all? Is the data any good? Then buy that answer by the hour. Cap it, and make the result a written report. Fix the price of the build that comes next. Most AI projects need both, in that order.

## Who pays for the overrun under each contract

Start with who gains from extra hours. The rest follows from that.

Here is a made-up example with round numbers. An hourly shop quotes 400 hours at $150 an hour. That comes to $60,000. Then the build runs long, the way builds do. The hours past the quote are the overrun.

| Hours the build really takes | Hourly (time and materials) | Hourly, capped at 500 hours | Fixed price |
|---|---|---|---|
| 400 | $60,000 | $60,000 | $60,000 |
| 500 | $75,000 | $75,000 | $60,000 |
| 600 | $90,000 | $75,000 | $60,000 |

Hours 401 to 600 are the same work in every column. On the plain hourly bill, they earn the vendor $30,000 more. You pay 50% over the quote. With the cap, you pay up to hour 500, and the vendor carries the last 100. With the fixed price, the vendor carries all 200.

No one has to do anything wrong for the first column to happen. Every hour was real. Each one was logged and billed. The contract pays for hours, so it pays for more of them.

Here is how I put it to buyers. Most firms bill by the hour. Their margin and your timeline are in direct conflict, and nothing in the contract fixes it.

The US government buys more software than anyone. It wrote the same point into its rule book, the Federal Acquisition Regulation, or FAR. Here is what the FAR says about time and materials. Such a contract "provides no positive profit incentive to the contractor for cost control or labor efficiency." Put simply, nothing in it pays the vendor to save you money or time.

So the FAR allows one in a single case. That is when no one can estimate, with any accuracy, how big or long the work will be. It also needs a ceiling price, which the contractor "exceeds at its own risk." A firm fixed price sits at the other end. It "places upon the contractor maximum risk and full responsibility for all costs."

## When is hourly the right contract for AI work?

When the work is a question, not a build.

AI has a kind of unknown that plain software doesn't. Can a model do the task, as well as you need, on your data? No one can honestly promise how often it will be right on files they haven't seen.

If the first job is to find out, a fixed price is a bet. One side will lose it. So a careful vendor guards itself. It pads the quote, or it shrinks the scope until it means little.

So buy the answer by the hour, and box it in:

- A ceiling in dollars, not an estimate.
- A stop date.
- A written answer at the end. It says what was tested, on which data, what accuracy it reached, and what a build would take.
- A test set you keep. Then the build that follows is judged on the same questions.

That gives most AI projects their right shape. First comes a capped discovery: a short, hourly study that finds out what works. Then comes the build at a fixed price, in phases. Each phase has its own win conditions and its own date. It is paid, then built. And the next phase waits until you accept this one in writing. A small build can be a single phase.

## The Seven-Part Scope: what a fixed price needs to hold

A fixed price is only as firm as the page it points to. That page is the statement of work. It says what gets built, by when, and for how much.

Every scope we sign has seven parts. The first is the deliverables, the things you get. Check the scope in front of you. If a part is missing, you have found where the first change order will come from. A change order adds work to a job, and adds cost.

| Part | What it pins down | Sample language (adapt with your counsel) |
|---|---|---|
| 1. Deliverables | Each thing handed over, item by item | "Vendor will deliver (a) the lead-routing workflow, (b) the admin dashboard, (c) the CRM integration and (d) the handover pack in Section 9." |
| 2. Architecture | What it runs on, and on whose accounts | "The system runs on Client's own cloud, repository and hosting accounts." |
| 3. Phases | Each with its own win conditions and date | "Vendor will not start a phase until Client has accepted the previous one in writing." |
| 4. Timeline | Calendar dates, never lengths of time | "Phase 1 acceptance: Friday 12 March 2027." |
| 5. Win conditions | Tests, not adjectives | "A phase is accepted when every win condition in Appendix A passes." |
| 6. What the vendor needs from you | Access, logins and feedback, each with a window | "Client provides access within 2 business days of a written request, and feedback within 3 business days of a delivered milestone." |
| 7. One price | A number that doesn't move for the vendor's delays | "The fee is fixed and does not change if a delay is Vendor's." |

Now look at what the list leaves out. An hourly rate. A blended rate, which is one average rate for a whole team. A "time and materials" line. An estimate.

An estimate is a guess on letterhead.

## How to write acceptance criteria for an AI build

Part 5 is where fixed-price AI contracts break. AI output varies, and "good" is easy to argue about.

Acceptance criteria are the tests that say a phase is done. We call them win conditions. Each one must be yes or no, and a stranger must be able to check it. If two fair people could disagree on whether it was met, it is too vague.

| The vague version | Why it fails | The same idea as a win condition |
|---|---|---|
| "The assistant answers accurately." | "Accurately" is an opinion. | "On the 200 questions in Appendix B, at least 190 answers match the reference answer and name the source document." |
| "Staff find the dashboard easy to use." | Ease is a mood. | "Five named staff complete the six tasks in Appendix C unaided, each in under three minutes." |
| "The system is secure." | Secure against whom? | "A user on Team A cannot read Team B's records: all 12 access tests in Appendix D pass against the live database." |

Every good row ends in a count. That matters more than it looks.

RAND, a US research group, talked with 65 experienced data scientists and engineers about why AI projects fail. The most common root cause was the leaders. They misread the problem the AI was meant to solve, or they explained it badly. A vague "done" is that same failure, signed.

Four more rules matter for AI:

1. **Freeze the test set before the build starts.** Attach it to the contract. A test set written after the system exists tends to describe the system.
2. **Put the hard cases in on purpose.** Add the question with two meanings and the scan with a missing page. Add the request the system should refuse. Getting the easy questions right proves little.
3. **Agree how runs count.** A model's output changes from run to run. So decide up front. Does 190 of 200 mean one run, or each of three runs?
4. **Name the person who signs.** "Accepted by Client" is a department. "Accepted by the operations director" is a person with a calendar.

## Where the date really slips

In my experience, the most common cause of a slipped date isn't the engineering. It is a wait. Days for a login. Days for a password. A feedback round that took longer than the work it fed.

Count the days on this one. The engineer needs read access to your billing system. You forward the request to IT. IT wants a ticket. The ticket needs a manager's approval, and the manager is at a conference until Friday. No one did anything wrong. The date still moved four days.

A fair contract doesn't hide that, and it doesn't blame you for it. It writes the time windows down for both sides. Part 6 sets yours. The vendor's are the phase dates, plus how fast a reworked build comes back after your feedback.

Miss your window, and the date it touches moves by the same number of days, in writing. Miss theirs, and it doesn't.

A date also needs a cost the vendor feels. Ours is in every scope. Every build ships on the date in writing. If we miss it on our end, the build is free. We still finish it, and we wire you $5,000. Whatever you agree on, tie it to what the vendor controls. And make it cost them money.

Change orders get easier once the gaps are closed. Scope creep is a job slowly growing past what was agreed. It needs two gaps: a vague list of what you get, and a vague "done."

Write both down, and a new request shows up as new. It gets its own short scope, price and date before work starts. The current phase keeps its date. Rework inside the agreed scope goes on until you accept, because that is what the price bought.

## Is a fixed price more expensive than hourly?

Sometimes the quote is higher, and it should be. A vendor that carries the overrun prices some of it in. So compare the fixed quote with what the hourly contract will really cost. The table above shows how far that can drift from the estimate.

Two moves keep the extra honest. First, ask for a price on each deliverable, then strike the ones you don't need. A fixed price built from items falls when one goes. An hourly estimate rarely ties its hours to a thing you can cut.

Second, ask how the date was set. A team that has shipped many systems of this kind knows what they cost. It needs less cushion than a team that is guessing.

## Clauses to strike or question in an AI contract

- "Estimate" or "approximately" next to a price or a date.
- "Time and materials," "blended rate" or "then-current rates" in a build contract.
- "To Client's reasonable satisfaction" with no test attached.
- "Additional work" that is never defined.
- A date written as a length of time, such as "eight weeks from kickoff."
- Monthly bills for a build. Pay per phase instead, and accept each phase before the next.

## When not to use a fixed price

**Research.** If no one can write the win conditions, you are buying an answer, not a build. Buy it by the hour, capped and dated, as above.

**Small jobs.** A landing page or a basic CRM setup doesn't need seven parts and a penalty clause. Hire a freelancer by the job.

**Support after launch.** Once a system is live, the work becomes a stream of small requests with no finish line. A monthly support plan with a set reply time fits that better than either model.

**Slow access on your side.** Say your team takes ten days to grant any access. Tell the vendor before you sign, and write longer windows. Don't sign a short window you already know you'll miss.

## FAQ

### Is fixed price or time and materials better for AI development?

Fixed price is better for the build. Time and materials is better for research. Take a sample rate of $150 an hour. Then 200 hours of overrun adds $30,000 to an hourly bill and nothing to a fixed one. Use capped hourly while no one can define done. Then fix the price of the build once the test set and the deliverables are written.

### How do you fix the price of an AI project when accuracy is uncertain?

Split it. First, run a capped, hourly discovery that tests the model on your real data. It ends with a written answer. That answer gives the accuracy reached, the test set used, and what a build would take. Then fix the price of the build in phases. Write acceptance against that same frozen test set.

### What should an AI statement of work include?

Seven parts. List the deliverables and the architecture. Set the phases and a timeline in calendar dates. Write the win conditions. Say what the vendor needs from you, with windows in business days. Then name one fixed price. Each phase needs its own win conditions and date. Accept each one in writing before the next starts. A missing part is where the first change order comes from.

### What are acceptance criteria for an AI project?

They are pass or fail tests, written into the contract before the build starts. Each one ends in a count. One might be 190 of 200 test questions answered correctly, with the source named. Another might be 12 of 12 access tests passing. Freeze the test set and put in hard cases. Agree how repeated runs count, and name the person who signs.

### How do I prevent scope creep on an AI build?

Close the two gaps it needs: a vague list of deliverables, and a vague "done." Use the seven-part scope, with win conditions that end in counts. Then any new request is plainly new. It gets its own scope, price and date before work starts. The current phase keeps its date.

## Sources

- Federal Acquisition Regulation 16.601, Time-and-materials contracts: [acquisition.gov](https://www.acquisition.gov/far/16.601)
- Federal Acquisition Regulation 16.202-1, Firm-fixed-price contracts: [acquisition.gov](https://www.acquisition.gov/far/16.202-1)
- RAND, "The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed," August 2024: [rand.org](https://www.rand.org/pubs/research_reports/RRA2680-1.html)
- Our delivery guarantee, word for word: [commitments](/commitments).

The $150-an-hour shop, the 400-hour estimate, the 500-hour cap and every sample clause above are hypothetical illustrations, not Techify pricing or contract text.

## Related

- [Who owns the code your AI vendor writes?](/insights/who-owns-ai-code)
- [AI agency red flags](/insights/ai-agency-red-flags)
- [How long does it take to build an AI system?](/insights/how-long-does-it-take-to-build-an-ai-system)