The contract model decides who pays for the unknowns. On a well-understood build, such as a marketing site or a standard integration, the unknowns are small and either model can work. On an SI project they are larger and of a different kind: nobody knows how well a model will handle your data, or how clean that data is, until someone has measured it.
That is why the usual argument, fixed price for certainty against time and materials for flexibility, misses the point on SI work. The better question is which model fits which stage, and what the contract says about how quality is judged. This is how we would think about it from the buyer's side.
Why pure fixed price is risky for both sides
Fixed price works when the scope is definite and the risks can be named and priced in advance. US federal procurement rules say much the same thing: the Federal Acquisition Regulation treats a firm fixed price as suitable where specifications are reasonably definite and performance uncertainties can be identified and their cost reasonably estimated. Most SI projects fail that test at the start, for three reasons.
- Model behaviour is measured, not specified. An LLM does not either work or fail. It answers some share of questions well, and you only learn that share by testing it on your own questions. A requirement such as answers correctly cannot be priced until correctly has been defined and measured.
- Data quality is unknown until someone looks. Scanned documents, duplicate records, missing fields and stale content change the work far more than the feature list does, and they usually surface only once engineering starts.
- The ground moves. Model providers update and retire models, and the cost and behaviour of the one you planned around can change during the project.
Faced with that, a vendor quoting a fixed price on a vague scope has three options: add a large contingency, cut quality quietly to stay inside the price, or fight over every change request. None of these helps the buyer. And the buyer, holding a fixed price, often has no visibility into which of the three is happening until the system underperforms.
Should an SI project be fixed price or time and materials?
Usually neither on its own. Fix the price of a discovery stage with defined outputs, such as a data assessment, a draft evaluation set and a written plan. Then build on time and materials with a cap, or on milestones whose acceptance is tied to agreed scores on that evaluation suite. After launch, move to a retainer to run and improve the system. Whatever the model, write acceptance criteria, change control, ownership of every artefact and exit terms into the contract.
Why pure time and materials is not the answer either
Time and materials moves the risk to the buyer. You pay for the effort, whether or not the effort produces a working system, and scope can drift because nothing in the contract pushes back. The same federal rules are cautious here too: they allow time and materials only where the extent of the work cannot be estimated with reasonable confidence, and require a ceiling price that the contractor exceeds at its own risk. That ceiling is the idea worth borrowing.
Uncapped time and materials can still suit a team that is embedded in yours and managed by your own engineering lead. For a defined project with an outside vendor, it needs a cap, regular visibility of what the effort has produced, and a clear point at which either side can stop.
Match the contract to the stage
Uncertainty falls as an SI project moves forward, so the contract model can change with it. A typical project passes through four stages, much like the steps in how to build an SI agent for your business.
- Discovery: fixed price, fixed outputs. The scope here is the investigation itself, so it can be priced. Agree the deliverables in writing: a data assessment, a draft evaluation set built from real questions, a risk list, an architecture proposal and a recommendation on whether to proceed at all. A discovery that can end in do not build this is worth more than one that cannot.
- Prototype: fixed price for a defined question, or capped time and materials. The prototype answers one question, such as whether retrieval can find the right passage in your documents, and it is judged on evaluation results, not on how the demo looks. Be clear that a prototype is not a production system.
- Production build: capped time and materials, or milestones. By now the evaluation suite and the data assessment exist, so parts of the work can be fixed with confidence (integrations, user interface, infrastructure) while the parts that depend on model behaviour stay on capped time and materials.
- Run and improve: a retainer. After launch the work becomes monitoring, handling model changes, adding evaluation cases from real usage and tuning. A retainer with a written scope of service fits this better than a series of small projects.
Three hybrid models that work
- Fixed discovery, then capped time and materials. The most common pattern, and the easiest to start. The discovery outputs become the baseline for the build, and the cap is set from that baseline rather than from a guess. Ask for regular reports of effort against the cap and what it produced, and agree in advance what happens as the cap approaches: a review, a re-plan or a stop.
- Milestone-based. The build is split into milestones, each with a fixed fee and acceptance criteria. This gives the buyer predictability and the vendor a clear definition of done. It only works if acceptance is measurable, which on SI work means tying it to the evaluation suite rather than to a demo.
- Retainer for run and improve. A standing agreement that covers monitoring, incident response, model and provider changes, evaluation upkeep and a defined amount of improvement work. Write down what is in scope, how requests are raised and prioritised, and what is reported back.
What to write into the contract
Acceptance criteria tied to an evaluation suite
This clause does more to prevent disputes than any choice of pricing model. Instead of accepting a system because it looked good in a meeting, accept it when it reaches agreed scores on an agreed test set. Our piece on eval-first SI explains the practice, and RAG evaluation metrics covers what to measure for retrieval systems.
- The test set: who builds it, who labels it (your domain experts should be involved), and how it is versioned. Keep part of it back so the system cannot be tuned only to the questions everyone has seen.
- The metrics and thresholds: which scores must be reached for each milestone, and which failures block acceptance outright, such as leaking data from another user or acting without approval.
- The run: in which environment, on which model version, and who runs it. Both sides should be able to reproduce the result.
- What happens on a miss: a defined number of fix rounds, then a joint decision to re-scope, adjust the threshold in writing, or stop.
Change control, ownership and exit
- Change control: what counts as a change, how it is requested and priced, and who approves it. Name the SI-specific triggers in advance, such as data turning out worse than the discovery found, or a provider retiring the model the system was built on, so they are handled by process rather than argument.
- Ownership: a written assignment of code, prompts, evaluation data, retrieval indexes, pipelines and any fine-tuned weights, with model provider and cloud accounts in your name. The checks in outsourcing SI development to Pakistan apply wherever your vendor is based.
- Exit: your right to end the contract, what you receive for the work paid for so far, a handover plan with documentation and runbooks, and how the vendor's access is removed. Exit terms are easiest to agree before anyone needs them.
Pick the pricing model for the stage you are in, and let the evaluation suite, not the demo, decide when a stage is done.
Questions to ask a vendor about their proposal
- Why did you choose this contract model for this stage, and when would you change it?
- What would make you stop and re-plan, and how would we know early?
- How is acceptance measured, and can we see an evaluation report from past work?
- What happens to the price or the cap if our data turns out worse than expected?
- If we part ways mid-project, what do we keep?
A vendor that answers these plainly, including the uncomfortable parts, is usually one that has delivered SI work before. A vendor that offers a firm price on an undefined scope without asking about your data is telling you something too. If you are weighing several proposals, an independent SI consulting review of the contract terms before you sign can head off a dispute later.
Where Octalcode fits
Octalcode builds LLM applications, SI agents and RAG systems from a studio in Lahore, with a US presence in Austin. Our process page shows how we stage work, and we would expect any proposal from us to answer the same questions as anyone else's.
If you are unsure how to structure an SI contract, or want a second opinion on a proposal you already have, that is part of our SI consulting work. You leave with a written view either way, whoever you hire.