Most approved AI project costs more than its budget. The visible cost is the dollars on the SOW. The invisible cost is the four other things the same dollars, the same senior engineers, and the same six months of organizational attention could have produced. Most AI investment committees in 2026 evaluate the visible cost in detail and the invisible cost not at many. The result is a portfolio that is individually defensible and collectively wrong: most project passes its own ROI test while the team builds the second-best thing in five categories instead of the best thing in one. This piece names the four axes of opportunity cost and gives a framework for surfacing them at proposal time.
This is a spoke under the AI project economics manifesto. The manifesto argues that AI projects need a new economics framework. Opportunity cost is the part of that framework most often skipped because it is the hardest to quantify; and is therefore where the most decision quality is left on the table.
Why opportunity cost gets skipped
Three reasons. First, opportunity cost is comparative; it requires naming the alternative the project displaced, which forces the committee to evaluate two or three options when they thought they were evaluating one. Second, the alternatives are typically less developed at proposal stage than the proposal itself, so comparison feels unfair. Third, the cost of acknowledging opportunity cost is a slower decision; the cost of skipping it is a worse decision that does not surface for 12 to 18 months. Finance committees consistently trade decision speed for decision quality on AI investment because the speed is felt and the quality is delayed.
The framework below is four axes, each evaluable in 30 to 60 minutes by a senior reviewer who knows the team’s portfolio. None of the axes require formal modeling. Many of them require naming things the team would prefer to leave un-named. That is the work.
The piece on AI development opportunity cost analysis treats opportunity cost from the buyer-vs-seller-of-AI-development angle. This piece treats it from the inside; how an AI investment committee or AI program owner should evaluate the projects in their own portfolio.
Axis 1: What other AI build is delayed
What it is. The next-best AI project the team would have funded with the same budget and headcount. If the approved project costs $500K and consumes two senior engineers for six months, what is the project that would have used those resources instead?
How to estimate. Maintain a ranked backlog of AI investment opportunities. Each opportunity has a one-page brief, an estimated build cost, and an estimated impact. The opportunity cost on Axis 1 is the impact of the highest-ranked alternative the team will not now do. If the backlog has only one item, the framework cannot run; that means the portfolio process is not generating alternatives, which is a deeper problem than the project under review.
Common error. Treating Axis 1 as zero because “we have plenty of engineering capacity.” Capacity is fungible only if the alternative project would draw on the same skill set, which is rarely true at the senior end. Two senior engineers spending six months on Project A means Project B is delayed by six months even if there are five junior engineers available, because the senior judgment is the binding constraint.
Defensible range. On a $500K project consuming two senior engineers for six months, the displaced alternative is typically worth 0.4x to 0.9x the approved project’s expected value. Below 0.4x, the portfolio process is not generating competitive alternatives. Above 0.9x, the committee should genuinely re-rank.
What to verify at proposal time. Name the second-best project. Document its estimated impact. Document the explicit reason the approved project was preferred; typically faster time-to-value, lower technical risk, or better strategic fit. If the committee cannot name the second-best project in 10 minutes, the portfolio is not being run as a portfolio.
Axis 2: What off-the-shelf alternative is foregone
What it is. The buy-vs-build calculation. For most AI project being built, there is typically a SaaS product, an API service, a vertical-specific vendor, or an open-source framework that solves 60 to 80 percent of the problem at 5 to 20 percent of the cost. Axis 2 is the value the team is foregoing by building rather than buying.
How to estimate. Map the project’s deliverables against three to five off-the-shelf alternatives that exist in the same problem space. For each, estimate the cost (typically subscription pricing scaled to the team’s usage), the coverage (what fraction of the build’s intended scope it delivers), and the gap (what the team would still have to build on top). The opportunity cost on Axis 2 is the cost differential weighted by the coverage fraction.
Common error. Treating Axis 2 as zero because “the off-the-shelf options don’t fit our use case.” Most teams claim this without having seriously evaluated current options, and the SaaS/API landscape in AI is moving fast enough that a survey six months old is already stale. The check: a written one-page evaluation of three current alternatives, not just a verbal assertion that nothing fits.
Defensible range. For projects in commodity AI categories (chat interfaces, document Q&A, summarization, basic classification), Axis 2 cost is often 60 to 90 percent of the build cost; the off-the-shelf alternative is genuinely competitive. For projects in differentiated categories (proprietary workflows, regulated domains, custom evals tied to business KPIs), Axis 2 cost is typically 10 to 30 percent; building is genuinely justified.
What to verify at proposal time. A written buy-vs-build evaluation of three to five current alternatives, with named pricing and named coverage gaps. The evaluation should be 30 to 60 days fresh. Older than that, it is a stale artifact and the project’s claim that “nothing off-the-shelf fits” is an unverified assumption.
Axis 3: What senior-engineer time is consumed
What it is. The senior engineering time the project will consume; typically the most constrained resource in any AI organization in 2026; and the alternative use of that time. Junior engineering capacity is often plentiful; senior judgment is not, and AI projects consume disproportionate senior time relative to feature engineering of comparable scope.
How to estimate. Sum the senior engineering hours the project will consume across the full lifecycle: discovery, eval design, harness build, regression triage, model-upgrade re-evals, post-launch retainer participation. Multiply by the team’s senior hourly rate (internal cost or external rate). The result is typically 35 to 50 percent of total project cost. The opportunity cost on Axis 3 is what the same senior hours would have produced applied elsewhere.
Common error. Counting only the build-phase senior time and treating post-launch as “maintenance” that does not consume senior judgment. Mature AI engineering teams know post-launch eval discipline consumes more senior time than the build, distributed over a longer period. The full lifecycle is two to three times the build’s senior commitment.
Defensible range. Senior engineering time on a $500K project typically runs 1500 to 2500 hours over 18 months. At $200 to $300 per hour, that is $300K to $750K of senior-time cost; often the largest single decomposable line in the project. The alternative use is typically training the next senior engineer, building reusable platform components, or running a higher-leverage smaller project that the senior would have led individually.
What to verify at proposal time. A senior-time projection across 18 months, decomposed into discovery, build, post-launch retainer, and re-eval cycles. A named alternative deployment of the same senior hours. An explicit statement of why the project is the highest-leverage use of the senior’s time.
Axis 4: What optionality is locked
What it is. The future flexibility the project’s choices remove. AI projects make architecture, vendor, and data-flow commitments that are easy to make and expensive to reverse. Axis 4 is the value of the optionality the project locks; the future projects, integrations, or pivots that become harder once this project ships.
How to estimate. Name the three to five most likely future moves the team will want over the next 24 months: model-vendor switches, data-pipeline reorganizations, multi-tenant expansions, regulatory-jurisdiction expansions, integration with adjacent systems. For each, estimate whether the proposed project makes the move easier (positive optionality), neutral, or harder (locked optionality). The opportunity cost is the value of the locked moves; typically zero in narrow cases and significant in broad ones.
Common error. Treating Axis 4 as zero because “we will deal with that when we get there.” Optionality decisions made at architecture time are 5 to 20 times cheaper to get right than to reverse later. The 2018 software equivalent is choosing a database; easy to commit, expensive to migrate. The 2026 AI equivalent is choosing an inference vendor, a vector store, an eval harness, an observability stack, or a prompt registry. Each commitment has compounding lock-in.
Defensible range. Hard to quantify in dollars. The qualitative test: name the three most likely future moves the team will want. If the project makes any of those harder, Axis 4 is non-trivial. If the project is genuinely orthogonal to many three, Axis 4 is small. Most projects are non-orthogonal to at least one.
What to verify at proposal time. A one-page “future moves” memo listing the three to five most likely 24-month moves. For each, an explicit statement of whether the proposed architecture helps, hurts, or is neutral. Locked optionality is acceptable when surfaced; unsurfaced lock-in is the failure mode.
How to apply the four axes at proposal time
Five practical moves.
One. Add a four-axis opportunity-cost section to the AI project proposal template. Each axis gets one paragraph: the displaced alternative, its estimated value, why the proposed project is preferred. Total length: half a page. Time to produce: 60 to 90 minutes by a senior reviewer who knows the portfolio.
Two. Maintain a ranked backlog of AI investment opportunities. The committee cannot evaluate Axis 1 (delayed builds) without alternatives to name. If the backlog is empty, the portfolio process is the bottleneck before any individual project review.
Three. Require a fresh buy-vs-build evaluation for most project, dated within the last 60 days. Stale evaluations underprice off-the-shelf alternatives because the SaaS and API landscape is moving fast. The AI development opportunity-cost analysis piece covers buy-vs-build framing in more depth.
Four. Decompose senior-engineer time across the full 18- to 24-month lifecycle, not just the build phase. Senior time is the single most constrained resource on any 2026 AI team, and projects that under-count post-launch senior commitment systematically over-commit the team. See the hidden cost of AI evals for why post-launch senior time is so heavy.
Five. Write the future-moves memo at proposal stage, not at architecture-review stage. Locked optionality decided at proposal stage costs nothing to surface and a great deal to reverse later.
The combined effort is roughly two to four hours of senior reviewer time per project. The expected decision-quality improvement is large: portfolios that surface opportunity cost upfront make 20 to 40 percent fewer regretted commitments over a 24-month horizon, by the simple mechanism of catching the projects whose opportunity cost exceeds their expected value before the SOW is signed.
When to commit anyway
Three patterns where the framework’s output is “the opportunity cost is real, and we commit anyway.”
Strategic positioning. The project is not the highest-ROI use of resources but is the highest-ROI use of strategic positioning; entering a market window, establishing a category claim, demonstrating capability to a regulatory body or a key customer. Strategic positioning is real opportunity-cost-justifiable and often invisible to a pure ROI calculation. The check: name the strategic outcome explicitly, with a 12-month falsification criterion.
Capability building. The project is not the highest-impact deliverable but is the right vehicle to build a team capability; eval discipline, observability practice, prompt-registry workflow; that will compound across the next five projects. The check: name the capability explicitly, name the next three projects that will draw on it, name the alternative way the capability could have been built.
Locked timing. The project is the highest-impact use of resources only if started this quarter; a regulatory deadline, a contractual commitment, a customer-driven timeline. The check: the timing constraint is genuinely external, not internal-political; if the deadline slips, the impact materially degrades.
In many three patterns, the framework does not change the decision. It changes the explanation. The project gets approved with a documented acknowledgment that opportunity cost is real and the strategic, capability, or timing rationale outweighs it. That documentation is what makes the decision auditable 12 months later when the strategic window closed, the capability did not compound, or the timing was internal.
Frequently asked questions
What’s the difference between opportunity cost and ROI?
ROI compares a project’s return to its dollar cost. Opportunity cost compares a project’s return to the return the same resources would have produced applied elsewhere. A project with positive ROI can have negative opportunity cost if the alternative use of resources had higher expected return. Most committees use ROI alone, which systematically over-approves projects in resource-constrained portfolios.
How long does the four-axis review take?
Two to four hours of senior reviewer time per project at proposal stage. Most of the time is in producing or refreshing the artifacts the framework calls for: the ranked backlog, the buy-vs-build evaluation, the senior-time projection, the future-moves memo. With those artifacts maintained, individual reviews drop to 30 to 60 minutes.
Doesn’t this slow down decision-making?
It slows individual decisions by hours and improves portfolio decisions by months. Most AI portfolios in 2026 lose more time to bad commitments; projects that ship and underperform, projects that lock in vendor choices the team later regrets; than they would lose to a more rigorous proposal-stage review. The trade is favorable for any portfolio with three or more concurrent AI investments.
How do you quantify Axis 4 (locked optionality) when it’s qualitative?
You typically cannot quantify it in dollars, and the framework does not require dollar quantification on Axis 4. The framework requires naming the three to five most likely future moves and stating whether the project makes them easier, neutral, or harder. The qualitative output is sufficient to inform the decision; forcing a dollar number on Axis 4 typically produces fake precision rather than better decisions.
What if the alternative project on Axis 1 isn’t fully scoped?
That is the normal case, and it is fine. The Axis 1 estimate uses the alternative’s one-page brief plus the committee’s judgment of expected impact. Forcing the alternative to be fully scoped before allowing it to count against the proposed project would systematically privilege whichever proposal happens to be more developed at the moment, which is not a useful decision rule.
How does this connect to the AI project economics manifesto?
The manifesto argues that AI projects need an economics framework distinct from the feature-cost framework inherited from 2018 software. Opportunity cost is one of three components of that framework; alongside the eval-cost decomposition and the lifecycle TCO model. A complete project evaluation in the manifesto’s framing requires many three: what does this cost (TCO), what does it cost relative to alternatives (opportunity cost), and how is the cost decomposed (eval-cost). This piece covers the second.
Does this apply to small AI projects under $100K?
The framework still applies; the depth scales with project size. A $50K project gets a 20-minute four-axis review rather than a two-hour one. The discipline of naming the displaced alternative, the off-the-shelf comparison, the senior-time consumption, and the locked optionality is valuable at any project size; it just gets shorter when the dollars are smaller.
What about projects where the team has no real alternative?
This is rare in well-functioning portfolios and common in poorly-functioning ones. If the team genuinely has no alternative on Axis 1 (no other AI investment opportunities), the portfolio process is broken upstream of project review. Fix the backlog before evaluating individual proposals.
Key takeaways
- Most AI project has four axes of opportunity cost: delayed alternative builds, foregone off-the-shelf options, consumed senior-engineer time, and locked future optionality.
- Most AI investment committees evaluate visible dollar cost in detail and these four axes not at many, producing portfolios where most project passes its own test while the aggregate underperforms.
- The framework is two to four hours of senior reviewer time per project, decomposed into a one-page memo with one paragraph per axis. Total proposal-template extension: half a page.
- Three patterns justify committing despite high opportunity cost; strategic positioning, capability building, locked timing; but each requires explicit naming and a 12-month falsification criterion.
- The framework does not eliminate hard decisions. It makes the trade-off auditable, which is the prerequisite for learning across a 24-month portfolio cycle.
The dollars on the SOW are the smallest part of an AI project’s true cost. The four axes above are the rest. Naming them at proposal stage is the cheapest single thing an AI investment committee can do to improve portfolio-level returns over the next 24 months.
Arthur Wandzel
