AI transformation
What enterprise AI transformation actually costs - and where the money disappears
When an organization asks us for a quote on an AI project, the first question is almost always "what does it cost to build". That is the wrong question. Across the programs we have supported over the past two years, development itself was between a third and a half of the total cost. The rest was split across things most budgets never include.
The four cost components
1. Development and engineering. The part everyone prices: architecture, building the system, integrations, testing. The deeper the integration into core systems, the larger this becomes - and it is usually work that is hard to estimate before you look at the real API of the existing ERP or CRM.
2. Data preparation. This is where the surprise lives. A good model on disorganized data will give bad answers with total confidence. Cleaning data, defining a single source of truth, permissions, consistent field naming - none of it is glamorous, all of it takes time, and it is usually the precondition for success. On projects where the data was in poor shape, preparation cost more than development.
3. Running cost. Model spend is a budget line that keeps running after launch. It depends on volume, on context length and on the model you picked, and it can differ several-fold between two architectures. Build a monthly estimate early, then check it against real usage after a month in production.
4. Rollout and organizational change. Training, writing procedures, supporting teams, and the hours employees spend learning instead of working. That is a real cost even when it never appears on any vendor's invoice.
Why budgets break halfway
The most common reason we have seen an AI project stall is not technical. It is cash flow: the organization approved a budget for the build, the project ran three months long because of data, and the money earmarked for rollout was burned on development. The result is a system that works and nobody uses.
The way to prevent it is simple and unpleasant: budget rollout separately from development, and ring-fence it. For us that is a condition for starting a project.
How we price
We do not sell open-ended consulting hours. Every project is defined as an outcome with a success metric, a timeline and a budget. Before we start we run a two-week paid diagnosis, and at the end of it you hold:
- A list of use cases ranked by estimated return on investment
- A cost estimate for each of the four components above
- An estimate of monthly running cost for the first year
- One numeric success metric per use case
- A financing structure: equity, credit, and the grant tracks the project may qualify for
If the diagnosis shows the project will not return its investment, we will say so. Better to pay for two weeks than for a year.
One rule of thumb
If you are budgeting a first AI project, take the development estimate you received and multiply it by two to two and a half to reach the true first-year cost. That is not cynicism - it is simply what we keep seeing in the field. And if that multiplication makes the project not worth doing, it is better to find out now.
Want to talk about what you just read?
If the article touched something you are dealing with, we are happy to have a short, no-obligation conversation.
Book a meeting