Fixed price vs time and materials for AI projects

Choosing fixed price vs time and materials for an AI project comes down to how much of the work is actually known. Fix the price for well-defined engineering such as authentication, integrations and interfaces. Timebox the parts that depend on model behavior. Keep running costs such as model usage outside the build price entirely.

Most arguments about pricing models are really arguments about risk: who carries the cost when something takes longer than expected. This guide describes how to split that risk sensibly on AI work. It reflects how ImadDhin structures proposals and what the portal's own code shows about AI features, not a promise about any specific price.

Why pricing AI work is harder than pricing a website

A conventional web or mobile build is mostly known work. Screens, data models, integrations and deployment can be broken into tasks, and an experienced team can estimate them with reasonable confidence once the scope is clear.

AI features add a different kind of uncertainty. Whether a model extracts the right fields from a messy document, answers from the right source, or follows a multi-step instruction reliably is something you learn by testing with real data. The first approach may work well enough. It may need retrieval, a different prompt structure, a smaller task decomposition, a different model, or a human review step. None of that is visible from the brief.

Model providers also change underneath you. New versions arrive, older ones are retired, pricing changes, and behavior shifts between versions. A contract that assumes the AI layer is fixed for the life of the project is assuming something the industry does not provide.

What teams often get wrong

• Fixing the price of an unknown. A vendor who fixes the price of an unproven AI capability either pads the quote heavily or cuts corners when the unknowns appear.
• Open-ended time and materials with no checkpoints. Hourly billing without milestones, caps or decision points moves all risk to the buyer and removes the incentive to converge.
• Defining success as it works. Without agreed acceptance evidence, fixed-price AI work ends in a dispute about whether a demo counts as delivery.
• Bundling usage into the build price. Model calls, transcription and hosting scale with usage. Folding them into a one-time price guarantees that someone loses once traffic grows.
• Choosing the model by habit. Some buyers always want fixed price, some vendors always want hourly. Neither preference says anything about the actual project.

A practical approach: price by uncertainty

Instead of one contract model, split the project into phases and price each phase by how well it is understood. The structure below is a common pattern, not a rule.

Discovery: fixed and small

A short, fixed-price discovery phase turns a brief into a plan: the first workflow, the data sources, the integrations, the acceptance evidence and the open technical questions. Its output is a written scope and an estimate for the next phases. Because the deliverable is a document and a decision, a fixed price is easy to agree.

Technical spike: timeboxed

When the product depends on a model doing something specific, run a timeboxed spike against real, representative data. Agree the question in advance, for example whether invoices from these five suppliers can be extracted into this schema with this review step, and agree what happens at the end: continue, change approach, or stop. Time and materials with a hard cap fits this phase, because the point is to learn.

Build: fixed per milestone

Once the spike has answered the core question, most of the remaining work is ordinary engineering: interfaces, roles, integrations, admin tools, deployment, monitoring. Price it as fixed milestones with clear acceptance evidence. For the AI component, define acceptance against an agreed set of example inputs and the behavior expected for each, including what the system should do when it is unsure.

Run and improve: capped time and materials or a retainer

After launch, the work changes shape: prompt and retrieval tuning, provider updates, new edge cases from real users, cost optimization. A monthly retainer or capped time and materials fits this better than a new fixed bid for every small change.

Implementation considerations

Write change control into fixed-price phases. A change request process with a short written impact note keeps a fixed milestone fixed without pretending nothing will change.

Separate the build price from running costs in every proposal. Model usage, vector storage, transcription, email, hosting and monitoring should be listed as drivers with the assumptions behind them, and ideally billed to accounts the client owns. That makes the client's cost of operation visible and portable.

Agree ownership of the evaluation set. The example inputs and expected behaviors used for acceptance are valuable in their own right. They become the regression tests that tell you whether a provider update broke something. The client should own them.

Define what a timebox means in practice: the number of days, the question it answers, the reporting cadence, and the decision at the end. A timebox without a defined decision tends to become open-ended billing with a different name.

Plan for provider change. Structure the integration so the model and provider can be swapped behind one interface, and say in the contract who pays for adapting to a provider deprecation during the build and after it.

Trade-offs

Fixed price gives budget certainty and puts delivery risk on the vendor. The costs are a risk premium in the quote, less flexibility to change direction, and a strong incentive to read the scope narrowly.

Time and materials gives flexibility and usually a lower rate for the same work, because the vendor is not pricing in risk. The cost is budget uncertainty, and it depends heavily on trust and on the vendor's discipline in reporting progress.

The phased approach balances the two but adds overhead: more decision points, more documents, and the discipline to actually stop or change course when a spike says the idea does not work. That overhead is worth it on projects with meaningful AI uncertainty, and not worth it on a small, well-understood build.

A hybrid that is often overlooked is fixed price with a capped variable component: a fixed milestone plus an agreed pool of hours for AI tuning that is billed only if used. It keeps the known work predictable while being honest about the unknown part.

Lessons from ImadDhin work

The observations below come from the code of this portal and are labeled as implementation-level observations. They are not claims about client pricing or outcomes.

The portal's agent routes requests through a primary model provider and keeps a fallback path for failures, and provider errors are translated into visitor-safe messages rather than exposed. That design exists because provider behavior and availability change independently of the product. Any contract that treats the AI layer as a fixed, one-time deliverable ignores this ongoing work.

The free agent tier is capped at a small number of prompts, and heavier capabilities such as web research are gated behind a paid tier. That is a cost-control decision: model usage is a running cost that grows with each user, and it has to be managed as an operating expense, not absorbed into a build budget.

The project brief flow asks for a budget range and timeline before the written brief, and includes a separate advance-terms step. Framing the budget first helps match the pricing model to the project: a narrow budget with a fixed date points toward a fixed, tightly scoped first milestone, while an open research question points toward a timeboxed spike.

Common mistakes to test for in a proposal

• Does each phase say which pricing model it uses and why?
• Is there a defined decision at the end of every timebox?
• Are acceptance criteria for AI features written against example inputs, not adjectives?
• Are running costs listed separately, with assumptions, and billed to accounts you own?
• Is there a change-request process for fixed-price phases?
• Is responsibility for provider deprecations and model changes assigned, during and after the build?
• Do time and materials phases have a cap and a reporting cadence?

A proposal that fails several of these is not necessarily dishonest, but it leaves the risk allocation unclear, and unclear risk is where most disputes start.

When a simpler model is better

If the AI part is a thin, well-understood integration, such as summarizing text with a standard model call or adding a search box over a small document set, the uncertainty is low. A single fixed price for the whole build is simpler for everyone and perfectly reasonable.

If the work is exploratory from start to finish, for example a research prototype to test whether an idea is feasible at all, plain capped time and materials with weekly check-ins is more honest than an elaborate phase structure. Use the phased approach when the project genuinely mixes known engineering with real unknowns.

Choose the model per phase, not per project

Ask which parts of your project are known and which depend on how a model behaves, then price each accordingly. You can read how ImadDhin structures engagements and AI product development, send a project brief, or bring your scope to a 30-minute call and decide together which phases should be fixed and which should be timeboxed.