ROI and Budgeting AI Systems

Many execs are struggling to budget for their AI spend, this article offers some guidance on how to keep things flexible enough to keep you sane, while making sure ROI is not some vague notion you never see

We all feel the excitement around AI’s potential, but few projects see real measurable ROI. As systems and providers start to raise prices, you need a way to keep searching for that return (it is there), while also keeping a sensible budgeting approach.

ROI as a first order concern

Many AI systems just do what can be done, not what should be done. The main discipline is finding end-to-end work that you can speed up without sacrificing quality, and then using that as a benchmark. The key here is end-to-end. If you speed up one section but succumb to Parkinson’s Law in other parts, you aren’t making any progress. This is the common failure mode we see: local speed up that needs some tweaking or clean up downstream that negates the advantage.

Only when you start to look at work this way, you can start to link your AI systems to actual returns. This is often more a case of tweaking the approach (and sometimes stopping a project if it isn’t working) so you can see holistic speed ups. Now you can do X units of work per employee or per day, instead of Y (where X should be greater than Y obviously). That’s value.

Set a sane clock cycle

Another common failure mode is assuming every AI system needs to run in real-time and needs the strongest model. An example I’ve found helpful is preparing a morning briefing that includes project status reports and a quick survey of communication systems (slack or email). You won’t need it till 8am the next morning, and the data is ready to be processed at 5pm the day before. So you could theoretically have a slower model chew on it all night. This is a bit extreme, but many workflows have this pattern inherent in them, you don’t need up to the minute responses most of the time.

Even if you choose to use Claude for all your work, you can often break down the work into small chunks that can be done by Haiku in batches (which is the cheapest model, at a 50% discount) rather than using Opus dynamically. This kind of batching and timing is often the first step in making costs come down significantly. It’s also a great way to manage your inference availability if you go the sovereign AI route (which I’m a huge proponent of).

Time savings is an illusion unless more gets done

Having covered the naive aspects of cost and return so far, I wanted to call out that pure time savings doesn’t mean much. Keep Parkinson’s law in mind here.

Budget for experimentation in 2 categories

You’ll want to keep your existing workflows stable, but revisit them on some cadence to see if you can improve them. Have a sane set of evals ready but you can use past work as a benchmark so you know what good looks like. Speed is often not the main goal, but cost optimization and quality are where you can make gains.

The second category is new experiments. As I alluded to above, this only makes sense when you have an end-to-end value to set ROI against. Without it you’re learning how to do new things with cool tools (valuable in its own right), but that’s not the same as a business case.

Want this kind of thinking on your problem?