Guide

Proving the ROI of AI Coding Tools to a Skeptical VP

Your VP has seen a dozen vendor ROI decks and believes none of them. Good. Here is how to build a number that survives the person whose job is to poke holes in it.

The reason vendor ROI math bounces off a good executive is that it hides its assumptions inside a confident-looking total. A skeptical VP has learned to distrust exactly that. So the move is not a bigger number. It's a number with its work shown, its estimates labeled as estimates, and its realized savings kept strictly separate from its hoped-for ones. That is a story a finance-minded person can actually check, and checkable is what earns you the next round of investment.

Start with the cost, because you can actually know it

Most ROI conversations open with benefits and hand-wave the cost. Reverse it. Your cost is the one side of this you can pin down, so pin it down first. AI spend is migrating from flat per-seat fees to metered usage, and metered usage is invisible until you instrument it, so the real cost is often not the number on the seat invoice. Put a meter on actual usage, attribute it per person, and reconcile the total back to the real bill. When your cost figure sums to the invoice, the VP can trust it, and a trusted denominator is half the argument.

A side benefit: the instant you look, you usually find waste. Unassigned seats, overlapping plans, an automation quietly billing the expensive metered path when it could ride a subscription you already pay for. On one team, that kind of look surfaced roughly $8,000 a year of spend that was recoverable or misdirected. Handing your VP a cost number and a list of leaks you already closed is a very different meeting from asking for more budget.

Separate realized savings from identified savings

This is the single discipline that makes the rest credible. Keep two columns and never blend them:

  • Realized: money no longer being spent, or time already given back, that you can point to. Small and defensible.
  • Identified: a worklist of savings you believe are there but haven't banked yet. Larger and honest about being a forecast.

The temptation is to add them together into one impressive figure. Don't. A VP who catches you counting unbanked savings as real will discount everything you say afterward. A VP who sees you volunteer the distinction will believe the small realized number completely, which is the number you actually needed them to believe.

Put the value in a labeled estimate, with the assumption visible

Some benefits genuinely are estimates, and that's fine as long as you say so and show the input. When I let an agent carry eligible bug fixes end to end, I could report hard facts (57 fixes in twelve business days, a bit over $300 of model usage at list rates, a median around $7 per bug) and, separately, a labeled estimate of value: at a conservative half-day of engineer attention per small bug, that's several developer-weeks reclaimed, without spending feature capacity. I show the half-day assumption as an input, not a conclusion, so anyone can argue with it. An estimate with its assumption on the table is a conversation. An estimate presented as a fact is how you lose the room the first time someone checks your math.

Prefer time-and-capacity framing over a dollar sign

Engineering ROI converts to dollars badly, because "developer time saved" only becomes money if you do something with the capacity. So I usually frame it as capacity reclaimed and what it bought: bugs cleared without touching the roadmap, a reviewer's afternoon back, a class of toil retired. Let the VP apply their own dollar multiplier if they want one. Handing them the capacity and their own assumption to price it is more persuasive than handing them your dollar figure and asking them to trust your multiplier.

Name what you can't prove yet

There will be benefits you believe in and can't yet measure. Say so. "I can't give you a dollar figure for the incidents the guardrails prevented, because the point is that nothing happened, and what I can show you instead is capability we didn't have before." An executive who has sat through inflated decks will trust the person who marks the boundary of their own evidence. That trust is the actual asset. It's what gets you the next yes.

Take what helps

A durable ROI case is small where it's certain and clearly labeled where it isn't: a cost that reconciles to the invoice, realized savings kept apart from identified ones, value framed as capacity with the assumption shown, and an honest boundary around what you can't yet prove. That is the number that survives the skeptic, because you built it the way the skeptic would. Your finance culture and your VP will differ. Take what helps, skip what doesn't.

The mechanics live in two playbooks: tracking AI spend for the cost side, and letting an agent ship fixes for the value side. The AI coding tools ROI calculator runs this math with the whole formula on the page, and if the argument turns into one about capacity rather than money, the team capacity planner is the other half of it.

Get new guides by email

One email when a new playbook or guide goes up, nothing else. Unsubscribe anytime.