Build vs Buy for AI: Why the 3-Year Total Cost Number Changes the Answer Every Time

The Licensing-Only Cost Model Is the Wrong Model

A vendor quote shows three things: seat licenses, API usage tiers, and a Year 1 setup fee. Finance sees a number. The board sees a number. The CTO signs on that number. But the quote does not show every cost over 36 months.

Vendors quote what they control: access fees. They have no reason to count your engineering hours. They do not count your time fixing AI mistakes. They do not count debugging labor when they quietly update a model. They do not count your cost to leave at renewal. Those costs are yours. They are not in the document you sign.

Here is a common pattern. A team picks a SaaS AI platform on Year 1 per-seat pricing. Year 1 goes fine. In Year 2, usage grows and triggers a tier upgrade the contract allows without notice. The vendor pushes a model update. Outputs change. The team finds out through a support ticket. Three engineers spend several weeks finding and fixing the problem. By Year 3, all prompt logic and output parsers tie to vendor-specific formats. The cost to switch vendors now exceeds the original Year 1 license several times over. The renewal happens when the vendor holds all the power. The vendor did nothing wrong. The contract was honored. The cost model was simply incomplete from day one.

The diagram shows a pattern, not a measured figure. Licensing is the only cost the vendor controls. It shows up on invoices, so everyone sees it. Engineering labor, rework, maintenance, and exit costs all grow over time. None of them appear in the vendor quote. The 3-year total adds all five categories. The gap between the quote and the real total grows as the contract continues.

This is not the vendor's fault. The buyer's cost model is incomplete. My 7 years of electrical engineering in Luanda taught me this: a component quote and a total cost of ownership are two different documents. Hardware teams always build a 3-year lifecycle cost. AI procurement has not caught up to that standard. The NIST AI Risk Management Framework expects this rigor in its GOVERN function, which covers AI lifecycle cost and vendor risk. See NIST AI RMF 1.0.

The 5 Cost Categories That Belong in a 3-Year AI Total Cost Model

1. Licensing and Usage: What the Quote Covers

Seat licenses, API usage tiers, and setup fees are what the vendor invoice shows. Most organizations get Year 1 right. The risk comes later. Volume tiers can upgrade automatically as usage grows. Renewal prices drift up when early discounts expire. Overages appear mid-year when a product grows faster than planned. To estimate: multiply your current per-seat or per-call rate by a growth factor from your product roadmap, across all three years.

This maps to Build vs Buy Framework criterion 5 (3-yr total cost) and criterion 6 (vendor lock-in tolerance). Both need pricing details the vendor quote may not fully show.

2. Internal Engineering and Talent Cost

Every AI integration takes internal engineering time. On a SaaS buy path, this means: initial integration work, ongoing API client maintenance, schema and auth changes when the vendor updates, and debugging when vendor behavior breaks your output. On a build path, this means ML engineering salaries, compute costs, and tooling. To estimate: multiply your average fully loaded engineering hourly cost by estimated maintenance hours per quarter, across 12 quarters. Write down the hours estimate before signing. Revisit it after each major vendor release.

This maps to Build vs Buy Framework criterion 4 (in-house ML talent), which measures your team's ability to handle build-path cost. It also maps to criterion 8 (integration depth), which shows how much internal labor the chosen path needs.

3. Hallucination Rework and Output Quality Labor

When AI output is wrong, someone pays to fix it. That cost has two parts. The first is the direct labor of reviewing and correcting AI output. The second is the extra work created when a wrong output reaches a customer before anyone catches it. Neither shows up in the vendor quote. The 9-Question AI Spend Audit calls this criterion 8 (hallucination rework cost). To estimate: find the current error rate on AI outputs in a real process. Multiply by average correction time per error and by the annual output volume. Project that across three years as volume grows.

The EU AI Act (Regulation 2024/1689) adds to this cost. It puts documentation and accountability requirements on companies that deploy AI in covered use cases. That creates internal labor costs that appear in no vendor licensing agreement. See EU AI Act (Regulation 2024/1689) for deployer obligations.

4. Model Update, Maintenance, and Debugging Labor

SaaS AI vendors update their models on their own schedule. When an update changes model behavior, your team pays the debugging cost. This is not a vendor failure. It is the reality of depending on a model you do not control. The cost comes in two forms. The first is planned maintenance: testing and fixing prompts or parsers after a known update. The second is incident labor: unplanned debugging when a silent change hits production. Teams without a rollback path pay incident labor. Teams with one pay the lower maintenance cost. The difference is significant over three years.

This maps to Build vs Buy Framework criterion 10 (failure-mode visibility) and Cost Reality Check criterion 9 (internal AI-debugging labor). Naming it as a procurement question is the first step. ISO/IEC 42001:2023 covers supplier relationship requirements in AI management systems, including total cost of ownership. See ISO/IEC 42001:2023.

5. Migration and Exit Cost

What happens in Year 3 if the vendor raises prices, changes terms, or leaves the market? That question is invisible in Year 1 procurement. Migration cost includes several items: engineering hours to extract and reformat data from the vendor's schema, rewriting prompt logic that depends on vendor-specific APIs or models, reconfiguring downstream processes built on vendor outputs, and productivity loss during the move. Code ownership and data portability reduce this cost. Teams that keep source code and vendor-independent data schemas pay lower exit costs than those that do not.

This is most directly governed by Build vs Buy Framework criterion 6 (vendor lock-in tolerance). A low tolerance for lock-in means you should weight code ownership terms more heavily in the contract. It also means accepting a smaller renewal premium. A build path can eliminate recurring API cost entirely. sincllm documented this in the engineering post on fine-tuning a 7B model to replace an API, where removing a recurring API dependency was the main goal.

How to Use the Build vs Buy Framework to Score All 10 Criteria

The Build vs Buy Framework at /build-vs-buy/ scores 10 criteria across time-to-value, data residency, total 3-year cost, and vendor lock-in tolerance. The five cost categories above connect directly to six of those criteria. The table below shows which ones and how sensitive each is to cost.

The other four criteria (criterion 2: strategic differentiation, criterion 3: data sensitivity and residency, criterion 4: in-house ML talent, criterion 7: regulatory and audit) are not mainly about cost. But they can override a cost-favorable choice. A team without in-house ML talent (criterion 4 scores low) may correctly choose a buy path even if criterion 5 favors building. Hiring the talent to build would cost more than the 3-year SaaS premium. Scoring all 10 criteria before committing stops one dimension from driving the whole decision.

The table below scores the three main paths across all five cost categories.

The pattern is clear. The SaaS buy path is cheapest in Year 1 for licensing and internal engineering. Then costs grow in maintenance, exit, and licensing. The build path is the opposite: high Year 1 engineering cost, then lower recurring costs in Years 2 and 3. The custom consultant path sits between the two. Its total cost depends almost entirely on the contract terms you negotiate before work starts.

What the 3-Year Number Looks Like in Practice

Building the 3-year projection needs one input per cost category. All inputs are internal. You need your engineering rates, estimated maintenance hours per vendor release cycle, your current AI output error rate, and your view of how hard migration would be given your integration depth. None of these require the vendor's help to produce.

The checklist below names the inputs a CTO or CFO should gather before building the projection. It shows what is missing before you commit a number to a board presentation.

3-Year AI Cost Model Inputs:

1. Year 1 licensing cost from the vendor quote (seats, API tier, implementation fee)
2. Projected usage growth rate from your product roadmap (apply this to usage-based pricing tiers)
3. Renewal price assumption (use the contract's escalation clause, or ask for it explicitly)
4. Average fully loaded hourly engineering cost at your organization
5. Estimated integration-maintenance hours per quarter (count the API endpoints, output parsers, and downstream systems in your integration)
6. Vendor model update cadence (ask how often model versions change and how much notice they give)
7. Average debugging hours per major vendor release, based on past integrations or vendor documentation
8. Current AI output error rate for your use case (sample from production logs or from the vendor's stated accuracy figures for your task type)
9. Average correction time per error and downstream rework cost per correction
10. Migration complexity score: how many vendor-specific schemas, APIs, or data formats does your integration depend on?
11. Estimated migration engineering hours if you needed to exit at Year 3 (treat this as a project estimate, not a guess)

Teams that fill in all 11 inputs before signing consistently find the total 3-year obligation is much higher than the Year 1 license quote. The build path can become cheaper by Year 2 or Year 3 when licensing costs scale significantly. sincllm documented this in the engineering post on a local LLM powering a production website, where infrastructure cost was the primary concern. The buy path can still be the right answer when criterion 4 (in-house ML talent) scores low. Hiring the talent to build would cost more than the multi-year SaaS premium.

Model-tier switching sits between the two extremes. sincllm documented this in the post on distilling Haiku into a 7B model. Switching tiers is a cost lever when the 3-year licensing number on a premium API gets too high. It does not replace the full cost model. But it is a real variable that belongs in the Year 2 and Year 3 projections for any API-dependent buy path.

The Hidden Costs That CFOs Do Not See Until the Renewal

Three cost categories stay hidden from finance until a renewal or audit forces them into view.

Shadow AI subscriptions. Teams across an organization buy individual AI tool subscriptions without central procurement review. These costs get booked as software expenses, travel, or miscellaneous. Finance does not see them as AI spend. The Cost Reality Check criterion 7 (shadow AI spend) asks a direct question: does your organization have a full inventory of AI subscriptions, including team-level and individual purchases, and does finance see them all in one place? The 9-Question AI Spend Audit gives you the method to surface this inventory before the renewal arrives.

Auto-renewal exposure. Most SaaS AI contracts renew automatically unless you cancel within a notice window. If the window is 30 or 60 days, and the engineering team found a problem 90 days before renewal, the company locks in for another year before the issue is resolved. Auto-renewal exposure is Cost Reality Check criterion 6. The cost of missing the cancellation window is not just the license fee. It is the full renewal amount plus all the negotiating power you lose by committing to another year without meaning to.

Internal AI-debugging labor booked as general engineering overhead. When a vendor model update breaks a downstream integration, the engineering hours get logged against the product team's sprint. Finance never sees them as an AI cost. This is Cost Reality Check criterion 9 (internal AI-debugging labor). Making this cost visible requires tagging those tickets in your engineering system. Naming it as a category is the first step. The free Budget Watchdog tool surfaces idle burn and cache-miss costs before they reach the finance team. The same discipline applied to debugging-hour tracking makes vendor-attributed engineering cost visible.

Build vs Buy Is a Framework, Not a Formula

Cost is criterion 5 of 10 in the Build vs Buy Framework. It is the anchor of this article because it is the criterion most organizations underweight in Year 1. But cost does not override the other nine criteria. It informs them.

Criterion 3 (data sensitivity and residency) can override a cost-favorable buy decision entirely. If the use case involves regulated data that cannot leave a specific jurisdiction, cost does not decide the answer. Criterion 9 (iteration cadence) raises the cost of the buy path when the team needs to change model behavior faster than the vendor's release cycle allows. Neither of these is a cost question. But both affect the real cost of the chosen path in ways the vendor quote does not show.

The decision is also hard to undo quickly. Moving off a deeply integrated AI platform mid-contract is expensive and disruptive. Moving at renewal is possible but still costly if the integration grew over 12 to 24 months. This is why the cost model matters most before you sign, not after. A 3-year projection built from all five cost categories, scored against all 10 framework criteria, is the minimum standard for a sound procurement decision. I apply this same lifecycle cost discipline to production AI systems. I treat a decision without a full cost model the way an engineer treats a component specification without a datasheet: incomplete, and not ready to commit.

This article is a cost-modeling guide, not financial advice. The framework it references is a decision tool, not a guarantee of outcome. Every organization's cost inputs are different. The 3-year projection is only as accurate as the inputs you use to build it.

Conclusion

The vendor quote you are holding is cost category 1 of 5. The other four are yours to estimate: internal engineering labor, hallucination rework, model-update maintenance, and migration/exit cost. They grow together as the contract matures. A 3-year AI contract signed without modeling all five is a commitment to an unknown obligation.

The 9-question AI spend audit surfaces the hidden cost categories that belong in your 3-year model. Get it at the AI Cost Reality Check. For the full 10-criteria procurement decision, including the non-cost factors that can override a cost-favorable answer, the Build vs Buy Framework at /build-vs-buy/ is the resource this article has built on throughout.

Score the criteria before you sign. The cost model is not the whole decision. But it is the part most often missing when the renewal arrives.