What Drives the Cost of an AI Project?
AI project cost is driven far more by data readiness than by model development. The five factors that move the number are the state of your data, whether the problem is already well defined, integration surface, accuracy requirements, and who runs it after launch. Model building is usually the smallest line item.
Why AI Quotes Vary So Much
If you ask three firms to price the same AI project, you will often get three numbers that are not within a factor of five of each other. That is not usually because they disagree on day rates. It is because "build us an AI solution" is not a scope, and each firm has silently assumed a different one.
Here is what actually drives the cost, in the order it matters.
1. The State of Your Data
This is the single largest cost variable and it has nothing to do with AI.
If your data is already collected, joined, and reasonably clean, model development can start in week one. If it lives in six systems with inconsistent customer identifiers, or in spreadsheets on individual laptops, or has only been retained for four months, then the first phase of your AI project is a data engineering project.
That phase is frequently larger than the modelling work that follows it. We would rather say so during scoping than discover it in month two.
In most stalled AI projects we are asked to rescue, the model was never the problem. The pipeline feeding it was.
The practical implication: a two-week data readiness assessment before committing to a build is not a delaying tactic. It is what converts a wide range into a firm number.
2. Whether the Problem Is Actually Defined
"Use AI to improve customer retention" is a goal, not a specification.
"Predict which subscription customers are likely to cancel in the next 30 days, so the retention team can call the top 200 each week" is a specification. It names the prediction, the horizon, the consumer of the output, and the volume.
The second one can be scoped, priced and — crucially — evaluated. The first cannot, so any price attached to it is a guess with padding.
If you cannot yet write the second sentence, that is fine and normal. It just means the first engagement is a scoping exercise, and it should be priced and bounded as one.
3. How Much It Has to Talk To
A model that runs on an exported file and writes to a dashboard is a contained piece of work.
A model that has to read live from your core banking system, write back to your CRM, respect an existing role hierarchy, and stay available during business hours is a different order of project. The machine learning may be identical. The integration, permissions, monitoring and failure handling are where the effort goes.
Count your integration points early. It is the question that most reliably explains why two superficially similar projects price differently.
4. What Accuracy You Actually Need
Getting a model to reasonable accuracy is often quick. Getting it from reasonable to excellent is where budgets go.
The important discipline is deciding what accuracy is sufficient for the decision the model supports, rather than reaching for the best achievable number. A model that flags leads for a human to review can tolerate errors that a model auto-approving credit cannot.
Regulated decisions carry additional cost that has nothing to do with accuracy: explainability for every individual prediction, audit trails, bias testing and documentation. That is real work and it should be a visible line item, not a surprise.
5. Who Runs It After Launch
Models degrade. The world moves and the patterns they learned stop holding.
So a genuine cost question is whether you are buying a system your own team will operate, or one that comes with ongoing monitoring and retraining. Neither is wrong. But a quote that excludes this is not cheaper — it is incomplete, and the cost reappears in six months as a model quietly making worse decisions than the spreadsheet it replaced.
We hand over the retraining pipeline, monitoring and documentation as standard, precisely so this is a choice rather than a dependency.
What Usually Costs Less Than People Expect
The model itself. For most business problems, this is not a research project. Established techniques applied competently to good data solve the majority of commercial use cases. The frontier is rarely where the value is.
Foundation model API costs. Teams often worry about per-token pricing and then find it is a rounding error next to engineering time. Where it does matter, routing simple work to a smaller model handles most of it.
Infrastructure. Managed cloud services have made the hosting line much smaller than it was five years ago.
How to Get a Number You Can Trust
Bring the problem rather than the solution. "We think we need a chatbot" invites a quote for a chatbot; "our support team answers the same forty questions all day and response times are slipping" invites a conversation about whether that is the right build at all.
Then ask any prospective partner three questions: what do you need from our data before you can commit to this number, what happens if the accuracy target is not met, and who operates this after launch. The quality of those three answers tells you more than the figure at the bottom of the page.
If you want that conversation without a sales pitch attached, contact us and describe the problem in your own words.