The fixed-price AI project: what SMBs should demand from any AI builder

"Fixed price" gets used a lot in AI sales pitches. Most of the time what is actually being offered is a retainer with a prettier name, a vague statement of work, and a change-order process that dilutes the fixed part into something quite flexible.

Real fixed-price AI work exists. It looks specific. If you are evaluating a builder, here is the checklist that separates the genuine offer from the soft one.

The written statement of work

Real fixed-price projects have a written SoW you sign before any work begins. That SoW lists:

• The exact deliverables, in product language, not technical language.
• The acceptance criteria each deliverable must meet.
• The timeline with milestone dates.
• The price, the payment schedule, and what triggers each payment.
• What is explicitly out of scope.

If the SoW does not fit on two pages, it is not fixed. It is negotiable, and you will discover the negotiable parts after you have paid the deposit.

Acceptance criteria, not "we will iterate"

"We will work with you to refine" is the single most expensive phrase in AI procurement. It means the builder does not know when the job is done, so neither do you.

Acceptance criteria are the counter to this. They are specific, testable, and agreed up front. Examples from real projects:

• "Voice agent books appointments with no double-bookings, verified on 50 test calls before launch."
• "Chatbot resolves 60 percent or more of tier-one tickets in a 200-question test set."
• "Document extraction achieves 95 percent field-level accuracy on a 100-document sample."

If your build cannot be described in sentences like these, it cannot be contractually fixed.

The payment structure

A 50/50 split is the industry standard for fixed-price AI work. Half on signed kickoff, half on delivery against the written criteria. Anything requiring 100 percent upfront is a trust signal. Anything spreading payments across six milestones with vague completion markers is a retainer.

What you should own on handover

Ownership is the tell. At delivery, you should receive:

• The full code repository, in your version control.
• All prompts, configurations and model settings in version-controlled form.
• All third-party API keys, issued on your accounts, not the builder's.
• The deployed infrastructure running on your cloud, not the builder's.
• Written runbooks your team can follow.

If any of that lives on the builder's side, you are not buying a build. You are buying a subscription to a build.

Red flags

Five things that should make you pause on any fixed-price AI quote:

1. No written acceptance criteria in the SoW.
2. "We need discovery before we can quote." Fine, pay for the discovery as a small fixed piece, then get a real quote. Open-ended discovery is a slippery slope.
3. Lock-in to a proprietary runtime only the builder can host.
4. Vague model and stack choices ("we will use the best AI available"). Good builders name the model.
5. No handover plan. Ask explicitly what a day-after-delivery looks like. If the answer is waffle, something is wrong.

The two-page test

A genuinely fixed AI project fits on two sides of A4: deliverables, acceptance criteria, timeline, price, payment terms, ownership, out-of-scope. If your quote is longer and less specific than that, ask why.