The AI business case that survives a CFO: total cost of ownership, not build cost
Bottom line: Most AI business cases model the cost of building the system and stop there, which is why so many are approved in the meeting and abandoned within the year. An AI investment has three distinct costs that behave differently over time — build, run, and switch — and the case that survives a CFO models all three, prices on usage-based cost rather than the old software assumption, and states in advance the condition under which it will be stopped.
Most AI business cases model the wedding and forget the marriage
The typical AI business case is a build estimate wearing the costume of a financial model. It tallies the people, the time, and the integration work required to ship the system, projects a benefit, and presents a return. It is clean, it is confident, and it is missing most of the cost. The build is a one-time, front-loaded expense — the wedding. The system then has to run, in production, for years — the marriage — and the marriage is where the money actually goes and where the investment is actually won or lost.
This is not a small omission, and its consequences are well documented. A large share of generative AI projects are abandoned after proof of concept, and a 2025 report from MIT's NANDA initiative found that the large majority of enterprise GenAI pilots delivered no measurable return to the profit-and-loss statement. Some of that is bad project selection. But a great deal of it is business cases that were never financially honest in the first place: they passed the approval meeting on a build number and then collided with running costs nobody had modeled. A case that omits the marriage does not save money. It defers the reckoning to a budget review where the people who approved it are no longer in the room.
A build estimate is not a business case. It is the down payment, presented as the price.
AI broke the SaaS cost assumption your finance team still uses
There is a deeper reason these cases fail, and it sits in an assumption your finance organization has used reliably for fifteen years. In traditional software, the marginal cost of serving one more user is close to zero. You build the product once; every additional customer is almost pure margin; scale is unambiguously good for the unit economics. Whole disciplines of SaaS forecasting are built on that single fact.
AI breaks it. An AI system that calls a model incurs a real, recurring cost every time it runs — compute for inference, and around it the cost of monitoring, human review, and retraining. That cost scales with usage rather than vanishing at scale. More customers and more engagement mean more cost, not just more revenue. The unit economics have inverted relative to the software your finance team is used to, and a business case or a price built on the old assumption will mislead in a specific and dangerous direction: it will look better the more the product is used, exactly when the truth is the opposite. Inference costs have been falling, which helps, but they have not fallen to the zero-marginal-cost world that classic SaaS math assumes (Stanford HAI, AI Index Report 2025). Until your model accounts for cost that grows with usage, your forecast is describing a different business than the one you are in.
The Three Cost Curves
An AI investment has three costs, and the reason to separate them is that they have different shapes, different owners, and different risks.
Exhibit 1. Three costs that behave differently over time. Most business cases model only the first.
The first is Build — one-time and front-loaded. It is the cost of getting to launch, it is owned by engineering, and its characteristic risk is the overrun. It is also the only curve most business cases model, which is the entire problem. The second is Run — recurring, and rising with usage. It is inference at production volume plus evaluation, monitoring, human-in-the-loop review, and retraining. It is owned by operations, its characteristic risk is silent growth, and over a multi-year horizon it is usually the largest of the three. The third is Switch — latent, low for a long time, then spiking. It is the cost of being wrong: of discovering the system is mis-scoped, or that you are locked into a vendor whose price has moved, or that you must migrate. It is owned by strategy, and its risk is the one nobody budgets for because, until it triggers, it looks like zero.
A business case that models only Build is describing the smallest and least risky of the three curves and calling it the cost of the project. The CFO-proof case puts all three on the same axis and is honest about which one dominates over time. It is almost never Build.
The TCO iceberg: what's under the build line
The clearest way to see the omission is as an iceberg. The build cost is the tip above the waterline — the part visible at sign-off, the part the approval meeting sees. The mass that decides the investment sits below the surface.
Exhibit 2. The build is the tip; the running marriage is the mass under the water.
Under the waterline is the running marriage: inference at production volume, evaluation and monitoring, human-in-the-loop review, retraining and drift management, security and audit and compliance, integration upkeep, and the migration and lock-in exposure that constitutes switching cost. None of these are exotic; every one is foreseeable. They are simply below the line where most cases stop looking. A CFO-grade business case is, in large part, the discipline of pulling each of these submerged items above the waterline and putting a number — even a rough, explicitly-assumed number — against it before sign-off. The precise figures matter less than the act of refusing to pretend the submerged mass is not there.
The build is the tip. The running marriage is the mass under the water — and the mass is what sinks the investment.
Running the case on Monday
Take a single project and cost it two ways. (This is an illustration, not an account of any specific engagement.)
Exhibit 3. The cheaper case on paper is usually the more expensive one in practice. Illustrative, not a client account.
The first is the wedding case. It costs the build — people, time, integration to launch — and assumes margin will improve with scale, the way classic SaaS does. It carries no kill condition, because in this framing success simply means shipping. It is the cheaper case on paper, so it is the one that gets approved. Then usage grows, the running costs grow with it, the margin moves the wrong way, and at the next budget review the project is quietly killed — after the build was spent and the operating losses accrued.
The second is the marriage case. It costs build, run, and switch across the asset's whole life. It models margin under usage-based cost rather than assuming it. It states a kill condition up front and runs a sensitivity on the run curve, because the run curve is the one most likely to be wrong. It is the more expensive case on paper, and it is harder to get approved for exactly that reason. But it survives the year, and it survives the budget review, because nothing in it was hidden from the people who have to keep funding it.
Same project. The cheaper case on paper was the more expensive one in practice — because the cost it left out was the cost that mattered.
Where this argument fails, and what it costs
This frame has limits worth stating plainly.
Total-cost modeling can be taken too far, and when it is, it becomes its own failure mode. A business case padded with twelve speculative cost lines, each a guess multiplied by another guess, is not more rigorous than a build estimate — it is false precision, and false precision invites the same bad decisions as no precision, just with more decimal places. The discipline is to model the three curves honestly and run a sensitivity where the inputs are genuinely uncertain, not to manufacture spurious detail. There is also a category of investment that should not be subjected to a strict total-cost-of-ownership return at all: genuine research, strategic options, and capability you are building ahead of demand. Forcing those through a marriage-grade ROI gate on day one will kill the exploration that an AI program needs to stay ahead. Total cost of ownership is the right lens for a production investment; it is the wrong lens for an option, and confusing the two is its own expensive mistake.
That bounds the claim without weakening it. Model the three curves for anything headed to production. Do not drown a real case in invented line items, and do not subject a genuine option to a production case's standard. The point is honesty about cost, not the appearance of rigor.
The decision
Before your next AI investment goes for sign-off, the move is concrete.
Require all three cost curves in the case — build, run, and switch — not the build alone. Require a sensitivity analysis on the run curve specifically, because it is the largest over time and the most likely to be wrong, and a case that cannot survive a doubling of its run cost is a case that has not been stress-tested. Require a stated kill condition before approval, so that stopping is a planned, dignified outcome rather than a late and embarrassing one. And price and forecast the product on usage-based cost, not on the zero-marginal-cost assumption your SaaS instincts default to.
Budget for the marriage, not the wedding. The build is the cheapest and least risky thing you will do; the running cost is where the investment is actually decided, and the switching cost is the one that will surprise you if you let it. A business case that is honest about all three is harder to approve and far harder to regret. This is the financial discipline behind the Economics gate described in the companion piece on why pilots never reach production — there it is a go/no-go checkpoint; here it is the model a CFO signs.
Sources
- Stanford HAI — Artificial Intelligence Index Report 2025. Inference price trends; cost per unit of capability falling but non-zero and material at production scale. https://aiindex.stanford.edu/report/
- Gartner. Public projection that the majority of generative AI projects are abandoned after proof of concept. https://www.gartner.com/en/newsroom
- MIT NANDA — The State of AI in Business 2025. Finding that the large majority of enterprise GenAI pilots showed no measurable P&L return.
- McKinsey — The State of AI (annual survey). Cost and ROI uncertainty among the leading barriers to capturing value from AI. https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai
- Deloitte — State of Generative AI in the Enterprise (2024–2025). Difficulty demonstrating value and managing cost as recurring obstacles to scaling. https://www2.deloitte.com/
Bottom-line summary (one line)
An AI investment has three cost curves — build, run, and switch — and the business case that survives a CFO models all three, prices on usage-based cost rather than the old zero-marginal-cost SaaS assumption, and states its kill condition before sign-off.
Suggested LinkedIn hooks (link back to the blog)
- Most AI business cases model the wedding and forget the marriage — they cost the build and ignore the years of running it. That is why they pass the meeting and fail the year. [link]
- AI broke the SaaS assumption your finance team still uses: cost no longer vanishes at scale, it grows with usage. A price built on the old math misleads in a dangerous direction. [link]
- The build is the tip of the iceberg. The run and switch costs are the mass under the water — and the mass is what sinks the investment. Here is the case that survives a CFO. [link]