How to contract AI development work

Match the price shape to what you can write down

Every price shape answers a risk question. Fixed price asks the provider to carry the estimate. Time and materials (T&M) keeps the estimate risk with the buyer, who also keeps more control over direction. Outcome-based terms tie some payment to a measured result.

Start with a practical test: can you write the statement of work yet? If you can name the deliverables, systems, data, acceptance examples, and access owners, fixed price or milestone pricing can be fair. If you cannot, a fixed price usually hides a large contingency or turns into change requests.

AI adds another unknown. The provider cannot know the quality of an assistant or agent until it is measured on your examples. Fix the scope, the test method, the versioned examples, and the acceptance owner first. Then let a measured baseline shape the build target.

Three questions decide the shape: what can be specified, what still needs discovery, and who controls the causes that decide the result.

This also keeps procurement and delivery aligned. A buyer may want a fixed number before the unknowns are understood, while the team doing the work needs room to test the workflow. Treat the first unknowns as work to resolve, not as risk to bury in a proposal.

Fixed price, time and materials, or outcome-based

Use the rows to compare what each proposal asks each side to carry. Many agreements combine shapes by phase because discovery, build, and later operation do not have the same uncertainty.

Fixed price Time and materials with a cap Outcome-based

Scope

Fixed price: Written and stable before work starts, with acceptance tests.

Time and materials with a cap: Still being discovered. Direction is set at each review.

Outcome-based: A measured result with an agreed baseline and metric.

Responsibility

Fixed price: The provider carries the estimate. Changes go through change requests.

Time and materials with a cap: You carry the estimate and steer the work. The cap limits exposure.

Outcome-based: The provider carries the result only for causes it controls. Your dependencies are named.

Access

Fixed price: Your inputs and approvals are listed as dependencies with dates.

Time and materials with a cap: Your decision makers are available at every review.

Outcome-based: The provider needs control of the main inputs and visibility into the measurement.

Continuity

Fixed price: Ends at acceptance, then the warranty period.

Time and materials with a cap: Ends at the cap or the agreed goal, with a stop point at each review.

Outcome-based: Runs for the measurement period. Later care and change are agreed separately.

Fit

Fixed price: You can write the statement of work and the test set.

Time and materials with a cap: Discovery, or early build where the scope can’t be written yet.

Outcome-based: The provider controls what drives the result and both sides can check it.

Many agreements combine shapes by phase.

Let risk follow control

Outcome-based terms can be fair, but only when the provider controls the main inputs that decide the outcome. If an assistant is paid per resolved request, the result may depend on your knowledge base, access approvals, adoption, policies, and exception handling. A provider asked to carry those risks will either price them heavily or dispute them later.

The cleaner version names the metric, the baseline, the measurement method, and the buyer dependencies. Both sides should be able to check the measurement. The metric should not reward behavior that looks good in a report but damages the workflow.

A fair split can use a base fee for the work and a limited outcome-linked part for the portion the provider controls. Buyer dependencies should be written as exclusions, not discovered during the first argument.

Apply the same idea to liability. The provider answers for what it delivered and tested. The buyer answers for the data, instructions, access, and later changes it supplied. Counsel should draft the clause, but the operating truth should be clear before drafting starts.

If nobody can say who controls a cause, do not attach payment or liability to that cause yet. Name the dependency first, then decide whether it belongs in scope, as an exclusion, or as a later change.

Price the work by phase

Discovery fits capped time and materials, or a fixed fee for a defined output. The output should be a statement of work, a first version of the test set, and a measured baseline on your examples. Either side should be able to stop after that phase.

Build can move to fixed price or milestones once the provider can plan the work against the accepted test set. A provider that cannot price its own plan after discovery is telling you something useful about the plan.

After acceptance, the warranty covers defects against the agreement. Operations, model changes, workflow changes, and improvements need their own agreement. Read what a warranty covers and what managed support adds before treating warranty as care.

UCS agrees the price shape for each phase before work starts: a monthly retainer for fractional engagements and time and materials for projects.

Usual price shape What you hold at the end

Discovery

Usual price shape: Capped time and materials, or a fixed fee for a defined output

What you hold at the end: A statement of work, a first test set, and a measured baseline

Build

Usual price shape: Fixed price or milestones

What you hold at the end: Accepted features, the test set results, and the named assets in your repositories

After acceptance

Usual price shape: Warranty for defects. Managed support or a new scope for the rest

What you hold at the end: An operating owner and a rule for re-running the test set after changes

Each phase should end with something you can hold and check.

Accept AI features against an agreed test set

Acceptance is where AI work differs from ordinary software. The same input may not always produce the same wording, so the agreement needs a test set and a judgment method, not a promise that the demo felt right.

Agree the test set before the build and version it. A set assembled afterward measures the build more than the need. It should contain:

• Representative real cases from your workflow, with the expected result for each.
• Hard and unusual cases, including cases where the right behavior is to stop, ask for help, or refuse.
• Cases with missing or conflicting evidence, insufficient permission, a failed tool call, or a consequential action.
• Prohibited results that fail acceptance on their own.

Agree how the set is judged. Write an overall threshold into the agreement, plus a stricter one for high-consequence cases, so a good average cannot hide a weak slice. Repeat runs where output varies. Measure latency and cost in the same acceptance run if they matter to release.

Your subject expert should supply cases and judge answers. The provider runs the set and shares the results. Name the person on your side who signs acceptance.

Record each acceptance run: build version, configuration, model and version, test set version, results, exceptions, and sign-off. The record matters later when someone asks whether a change is a defect or a new condition.

The test set is a deliverable. It lives in your repository and stays with you.

UCS delivers the agreed test set and its results into your repository, with the code, prompts, and configuration.

If the work is still a trial rather than scoped delivery, first design a trial that can reach production. This section is about writing acceptance into an agreement and tying it to payment.

What to get in writing

This is not legal advice. Counsel should draft the clauses. The operating terms, however, should be plain enough for the team to follow.

Name the assets that will be in your repositories: source code with history, configuration, infrastructure definitions, prompts, the test set, results, and runbooks. Do not rely on a broad handover phrase when specific artifacts decide whether you can operate the system.

Agree ownership of commissioned code and intellectual property in the terms. Separate rights to your application code and prompts from licenses for third-party models, libraries, and services. No engagement should assume ownership of a provider’s underlying model.

For data use, record who may use source data, prompts, evaluation examples, logs, and generated outputs, and for what purpose. Retention, deletion, and provider access should be agreed before data reaches a model service. UCS delivery practices require written permission before client data is used for unrelated work, including AI training.

The AI tools and providers term should say which systems handle your code and data, and how notice works when that list changes.

Also define change. A new data source, workflow, integration, model, or volume may change the scope, the price, the schedule, and the test set.

After acceptance: model and workflow changes

Model providers update their models. Your documents and workflows change too. Behavior can shift even when the delivered code has no defect.

Agree when the warranty starts and what it covers. A provider’s model update or your new data source is usually not a warranty defect. The agreement should say who re-runs the test set after a change, and whether that work is a change request, an improvement within managed support, or a new scope.

In UCS production AI work, changes to models, source content, or workflows need validation before they become the production default. The same rule belongs in the contract, because acceptance is not the last time behavior will be checked.

A decision checklist

Answer these before you compare proposals.

Which parts of the work can you specify today?

Separate the known scope from the discovery. A stable workflow, clear integrations, named examples, and an acceptance owner can fit fixed price or milestones. Unknown data quality, unsettled workflows, and missing acceptance examples usually need capped time and materials first, with a stop or re-scope point. Do not force one price shape across both kinds of work.

Who controls the inputs that decide the result?

List the data, access, approvals, adoption, policies, and operational choices that affect the metric. Keep outcome risk away from causes the provider cannot control. If an outcome term stays in the agreement, name buyer dependencies and exclusions so the metric does not become a proxy for unrelated work. The cleanest metric is one both sides can inspect.

Who supplies the test cases, and who judges them?

Name the subject expert who supplies representative cases and the person who signs acceptance. The provider can run the test set, but your side must judge whether the result fits the work. Without that owner, acceptance becomes a debate about taste after the build is finished. Cases should include routine work and the stop cases that matter.

What happens if a threshold is missed?

Decide before the run. The options may be fixing and re-running within an agreed window, accepting with a recorded exception, treating the gap as a scope change, or rejecting the result. A missed threshold should trigger a written route, not a negotiation invented under pressure. Record who can choose each route.

How will you see spend against the cap?

For capped time and materials, agree the cap, reporting rhythm, review cadence, and the point where either side can stop or re-scope. A cap without visibility only limits the end number. You still need to see whether discovery is producing a statement of work and a usable test set. If it is not, pause before more budget is spent.

Which assets will be in your repositories at the end?

Write the list into the agreement: source code with history, configuration, infrastructure definitions, prompts, test set, results, and runbooks. Also name what remains under third-party licenses. Handover depends on the assets you hold, not on the phrase used to describe cooperation. Ask where each asset will live and who can access it.

Who operates the system after the warranty?

Name whether your team, managed support, or a transfer arrangement owns the system after the warranty. AI systems also need someone to validate model, source content, and workflow changes. If that owner is missing, the build may be accepted without being ready for daily use. Agree the owner before launch pressure arrives.

When another engagement fits better

If your side has nobody to review the provider’s work and recommend acceptance, compare a fractional CTO with a tech agency. The missing role may be decision ownership, not another contract clause.

If the work is still a trial that has not reached daily use, settle whether it is ready for production before pricing a build. If the surrounding application matters as much as the AI, product engineering may be the better home for the scope.

Bring the workflow and a few acceptance examples

Bring the workflow, what is decided and what is not, a few sanitized acceptance examples, and cases where the right answer is to stop. Name who will sign acceptance and share budget and timing constraints if known.

Do not send credentials, customer records, confidential code dumps, or production datasets in the first message. Describe the boundary first.

You can also email hello@ucs.tech with a short description of the workflow and the acceptance examples you already have.

Questions before we start

Should AI development be fixed price or time and materials?

It depends on how much of the work you can write down and who controls the result. Fixed price fits a scope and acceptance tests you can specify. Capped time and materials fits work that is still being discovered. Many agreements use both, one per phase.

When does outcome-based pricing work for AI development?

When the provider controls the main inputs that decide the result, the metric and baseline are agreed, and both sides can check the measurement. If the result depends on your data, approvals, or adoption, keep those as named exclusions or use a base fee with a limited outcome-linked part.

How do we accept an AI feature that doesn’t give the same answer every time?

Agree a versioned test set before the build, with representative cases, cases where the right behavior is to stop or ask for help, and prohibited results. Set an overall threshold and a stricter one for high-consequence cases, repeat runs where outputs vary, and record each acceptance run.

Who should own the AI test set?

You should. Your subject expert supplies and judges the cases, the provider runs them, and the set is delivered into your repository with the code. You need it again whenever a model, data source, or workflow changes.

What should be delivered at the end of an AI development project?

Name the assets: source code with history, configuration, infrastructure definitions, prompts, the test set and its results, and runbooks. Agree ownership of commissioned code separately from licenses for third-party models and services.

Does the warranty cover changes in the model provider’s behavior?

Usually not, because a provider’s update is not a defect in the delivered work. Agree who re-runs the test set after a change and whether the work is a change request, an improvement within managed support, or a new scope.

How does UCS price AI development?

UCS agrees the price shape for each phase before work starts. Fractional engagements run on a monthly retainer, and projects are billed on time and materials. Budget and how scope changes affect cost and timing are agreed in writing.