Outsourcing software development works when the specification is stable and the acceptance test is obvious. Neither condition holds for most AI and data work, which is why a buyer who outsourced a customer portal without incident gets a bad result handing over a retrieval system on the same contract shape. The problem is not the vendor’s competence. It is that the contract assumes facts about the work that are not true.
What a fixed-scope outsourcing contract assumes
Four assumptions sit underneath it:
- You can describe the output before anyone starts building.
- The supplier can build without standing access to your production data.
- Correctness can be checked by a tester reading the spec.
- The work has an end date, after which nobody touches it.
For a booking flow, all four hold. For a question-answering system over ten years of contracts, none of them do.
Where AI and data work breaks each one
| Assumption | What actually happens |
|---|---|
| Scope fixed up front | Retrieval and extraction quality is discovered by measurement. The first evaluation run usually rewrites half the scope. |
| No standing data access | The team waits three to six weeks for VPN, DPA and a data-sharing sign-off. You pay for the idle time or the date slips. |
| Spec-based acceptance | Output is statistical. Until an evaluation set exists, “done” is a matter of opinion and the sign-off meeting goes badly. |
| Defined end date | Source data, model versions and prompts change monthly. Someone owns the system permanently. |
The second row causes more disputes than the rest combined. A supplier priced against a start date they cannot control will either load the quote or bill the waiting.
What the quoted price leaves out
Five lines routinely sit outside a fixed-price scope and land on you later:
- Data access and onboarding. Two to four weeks of legal and infrastructure work before the first commit.
- Evaluation tooling. Typically 10% to 20% of build effort: a labelled set, a scoring script, a place to see the score move. Skip it and you cannot accept the deliverable.
- Inference and compute. A monthly run cost that scales with usage, not a one-off.
- Drift and retraining. Budget continuing effort from go-live, not from month twelve.
- Exit. Documentation, credential rotation and the two or three weeks your own engineers spend learning code they did not write.
Compare the loaded total against internal cost rather than against headline day rates. Our current day rates by role give the input for that comparison, and the project cost calculator does the arithmetic across a team.
When outsourcing the whole thing is still right
Hand the work outside as a defined project when the target is unambiguous and you will not need the capability again: a warehouse migration with a known source and target, a one-off ingestion backlog, a platform upgrade with a vendor-published path. Also when you genuinely need someone else to carry the estimation risk and will pay 25% to 40% more for that transfer, which is the trade managed services and staff augmentation split between them.
Geography is a separate decision from contract shape. Time zone and legal jurisdiction change your review cadence more than they change the rate, which is the argument in our comparison of nearshore against offshore delivery.
Where our own model is the wrong answer
We rent senior engineers by the day. That fails in three situations, and we would rather say so now than in month two.
If nobody on your side can review a pull request or arbitrate an architecture decision, renting engineers puts unowned code into your estate. Hire or promote a technical owner first. If the real question is which use case to fund, or who may see which data, that is a decision problem and a few weeks of advisory work will serve you better than engineers billed by the day. And below roughly six weeks of work, onboarding overhead eats the benefit; use a fixed-price supplier who already has a template.
If you go ahead, structure it this way
Get data access agreed in writing before day one and put a start date in the contract that depends on it. Require a labelled evaluation set and a measured baseline as the first deliverable, before feature work. Keep source control, cloud accounts and CI in your own tenancy. Name one person on your side who owns the system after handover. Then review the measured baseline every fortnight, not the task board.