How to project AI ROI before you build with a calculator
Use an AI ROI calculator to project an AI feature's return before you write code: stated assumptions, honest ranges, and a gate that kills weak bets.
Shahriar P. ShuvoAI ROI & Strategy7 min read
Most "AI ROI calculators" are optimism machines. You type in a few hopeful inputs, the tool returns one big return number, and that number quietly justifies a build the team had already decided to do. A real projection does the opposite job. A good AI ROI calculator states its assumptions out loud, returns a range instead of a hero figure, and gives you a clean reason to walk away before you spend a sprint.
This is the work you do before a single line of code. You are not measuring anything yet, because nothing is shipped. You are forecasting, with error bars. The goal is not a confident slide for the steering committee. The goal is to kill weak bets early and to fund only the one feature whose low-end return still clears the bar. When the feature ships, you switch jobs and measure the ROI of an AI feature against the baseline you set. This post is the part that comes first.
Why an AI ROI calculator beats a gut call
An AI ROI calculator beats a gut call because it forces every optimistic assumption into a cell you can argue with. Gut calls hide their assumptions. A spreadsheet cannot.
The base rate is the reason this matters. MIT Sloan found that only 10% of companies obtain significant financial benefits from their AI work. Gartner puts a finer point on it on the delivery side.
Gartner predicts at least 30% of generative AI projects will be abandoned after proof of concept by the end of 2025, citing poor data quality, escalating costs, and unclear business value.
"Unclear business value" is the polite term for nobody projected the return and nobody could defend it when costs climbed. A projection is the cheap insurance against being in that 30%. It costs you an afternoon and a spreadsheet. The build it talks you out of costs you a quarter.
What goes into a projected ROI, line by line
A projected ROI has two sides, and most calculators get the cost side badly wrong. The value side is one metric you already track. The cost side is everything it takes to keep an AI feature alive, not just to ship it once.
Tie the value to a single metric the business already reports: retention, activation, conversion, or expansion. Pick one. If an AI feature cannot name the metric it moves, that is your answer and you can stop here.
The cost side is where AI differs from a normal feature. Inference is a recurring per-use bill, evaluation and guardrails are ongoing, and adoption ramps slowly, so first-year value is a fraction of steady state.
| Input | What it is | Typical range to model |
|---|---|---|
| Metric moved | The one tracked number the feature lifts | base × (1% to 8% relative lift) |
| Value per point | What one point of that metric is worth | from your finance model |
| Build cost | Design, engineering, data work to ship once | one-time |
| Inference cost | Model calls per active user per month | recurring, scales with adoption |
| Eval and guardrails | Quality checks, human-in-the-loop, monitoring | recurring |
| Adoption ramp | Share of users who actually use it in year one | 15% to 60% |
Notice that two of the six rows (inference, eval and guardrails) are recurring and that adoption is a discount on everything. A calculator that omits them will always look great and always lie. This is the heart of an honest ai cost benefit analysis: the costs that recur are the ones that decide marginal bets.
The formula: how to model AI ROI up front
The math is the plain return on investment formula, adapted so the AI-specific costs are visible. ROI is net return over total cost, expressed as a percent.
projected_value = metric_base × relative_lift × value_per_point × adoption_ramp
annual_cost = build_cost (amortized, year 1)
+ inference_cost × 12
+ eval_guardrail_cost × 12
projected_ROI(%) = (projected_value − annual_cost) / annual_cost × 100Run it three times, not once. That is the difference between a projection and a wish.
Example: AI onboarding assistant, metric = activation
metric_base = 10,000 new signups / yr
value_per_point = $4,000 per +1pp activation (from finance)
LOW lift 1%, adoption 15% → value ≈ $6,000 cost $90,000 → ROI ≈ −93%
BASE lift 4%, adoption 35% → value ≈ $56,000 cost $90,000 → ROI ≈ −38%
HIGH lift 8%, adoption 60% → value ≈ $192,000 cost $90,000 → ROI ≈ +113%That spread is the point. The same feature reads as a disaster, a marginal call, and a winner depending on three inputs you do not yet know. A single number would have hidden that. The range shows you exactly which assumption you need to de-risk first: here it is adoption, because it scales the whole value line.
State your assumptions or the number is fiction
Every cell in that model is a bet. Write the bets down. An assumptions register turns an argument about feelings into an argument about numbers, which is the only kind worth having in a budget review.
RAND studied why AI projects fail and found the leading root cause is that teams misunderstand what problem needs to be solved. In projection terms, that error lives in your top input: the metric and the size of the lift. Get the metric wrong and no amount of decimal places saves you.
WARNING
A single-point ROI estimate is the most dangerous output a calculator can produce. It launders a stack of optimistic guesses into one confident-looking number. Always carry a low, base, and high case, and make the decision on the low case.
Keep the register short and brutal:
- Metric and lift. Which tracked number, and the relative lift you are claiming. This is your highest-risk assumption.
- Adoption ramp. What share of users touch it in year one. Almost always lower than you hope.
- Recurring cost. Inference plus eval per active user, at scale, not at demo volume.
- Confidence. High, medium, or low on each. Low-confidence inputs are your test-first list.
Can you estimate AI ROI without building?
Yes, you can estimate AI ROI without building the real feature, and you should. The trick is to spend cheaply on the inputs you are least sure of instead of expensively on the whole thing.
A concept demo, a clickable prototype or a thin wrapper over a model on a sample of real data, buys you a defensible adoption and quality read for a fraction of a build. It will not give you the real number. It will tell you whether your base-case assumptions are plausible or fantasy, which is what a projection needs.
TIP
Spend your pre-build budget on the lowest-confidence input, not the most fun one. If adoption is the assumption that swings your range from loss to win, test adoption with a fake-door or a concept demo before you write production code.
This is how to forecast AI ROI before building without pretending you have certainty you do not have. You are not chasing a precise figure. You are checking whether the low case is survivable and whether the high case is worth the swing.
How a projected ROI helps you de-risk and kill weak bets
The real product of an AI ROI calculator is not a number. It is a decision: build, test more, or walk. Use the projection as a gate, and let the low case make the call.
This is also where projection becomes risk work. NIST's AI Risk Management Framework asks teams to map and measure the risk before you deploy, across govern, map, measure, and manage. A pre-build ROI projection is exactly that mapping step applied to value: you size the upside and the cost of being wrong before anything reaches a user.
| Projection signal | Decision |
|---|---|
| Low case clears the bar | Build. The downside is acceptable. |
| Base case clears, low case does not | Test the swing assumption with a concept demo, then re-decide. |
| High case barely clears | Walk. You are betting on best-case everything. |
| No metric names itself | Walk. There is nothing to project. |
The discipline to walk is the whole value. It is the same muscle you use to decide which AI features to build and, later, to kill an AI feature that is not paying off once it ships. Projection lets you kill the weak ones before they cost a sprint, which is far cheaper than killing them after.
Build the case so it survives review
A projection becomes an ai business case when you put the three cases, the assumptions register, and the decision rule on one page. Lead with the low case. A case that admits its downside survives a finance review that a single optimistic figure never will, because the skeptic in the room has nothing left to attack that you have not already named.
Then hand off. The projection ends the day you decide to build. Before you ship, set a baseline before shipping so the after-the-fact measurement has something to compare against. Projection and measurement are two different jobs: one forecasts the return, the other proves it.
Run the projection on every AI idea and you will spend on far fewer of them, which is the point. An AI ROI calculator that returns honest ranges is not there to make your feature look good. It is there to tell you which features deserve to exist, and to de-risk the few that do before a single user ever sees them.
TIP
Want the projection done for you, with the assumptions and ranges that survive a budget review? How the AX Audit works.
