Build vs buy for AI features: when a wrapper is the right answer
A build vs buy framework for AI features — where buying wins, where a thin wrapper is genuinely correct, and the three conditions that justify building AI infrastructure yourself.
The 838%-ROI claims in vendor pitches are built on assumptions that don't survive scrutiny. A grounded formula for AI automation ROI, and the costs that get left out.
Search "AI automation ROI" and you'll find headline numbers that don't survive five minutes of scrutiny: 838% ROI, a 25x return in year one, savings that would make the automation pay for itself in six weeks. These numbers are technically derived from real studies — they're just derived from assumptions chosen to produce a number worth quoting in a pitch deck, not a number worth planning a budget around.
Here's the skeptical, engineer's version: which assumptions inflate these claims, and a formula you can actually run on your own numbers.
A common move is to price the task being automated at its fully-loaded labor cost — salary plus benefits plus overhead — and then claim the entire figure as savings. That's only true if the automated hours convert directly into headcount reduction or into hours redeployed to genuinely revenue- generating work. In practice, most automation frees up fractional time across a team — twenty minutes here, an hour there — that doesn't reduce a salary line or get redeployed to anything measurable. It reduces overtime, or backlog, or stress. Real, but not a line item you can put in a savings column at the fully-loaded rate.
If you can't point to a specific headcount decision or a specific higher-value task the freed time now goes to, discount the savings claim heavily — the honest version of "we saved 10 hours a week" is closer to "we reduced backlog pressure by 10 hours a week," which is worth something, just not the fully-loaded dollar amount of those hours.
This is the single biggest inflator. Vendor case studies quote savings as if every instance of the task is now automated. Real systems, on real documents or real conversations, automate 60-80% of volume at launch and improve from there as the exception cases get identified and handled. The other 20-40% still needs a human — often a more skilled and more expensive human than before, because they're now only seeing the hard cases.
Run your ROI at your actual expected automation rate, not the ceiling. If a vendor's number assumes 100% and won't show you what it looks like at 70%, that's the number to ask for before you sign anything.
Related to the above: the human time spent on the 20-40% that doesn't automate cleanly is rarely subtracted from the savings claim, even though it's real ongoing cost. Worse, exception handling on an AI system is often more time-consuming per case than the old manual process, because the human now has to figure out why the automation got it wrong before fixing it — which requires understanding both the case and the system's failure mode. Budget for this as an ongoing line, not a rounding error that disappears after a training period.
The build cost is visible and one-time. The costs that follow are recurring and usually absent from the ROI slide entirely:
A pitch that shows build cost once against projected savings forever is comparing a one-time number to a recurring one and calling the difference ROI.
Net monthly saving:
Net monthly saving =
(automation rate × fully-loaded monthly cost of the task)
− (ongoing inference and hosting cost)
− (human time on exceptions × their fully-loaded hourly rate)
− (monthly allowance for monitoring and maintenance)
Payback period:
Payback (months) = one-time build cost ÷ net monthly saving
Run this with your real automation rate — start with 60-70% for a first build, not the best case from a vendor deck — and price the monitoring allowance at a fraction of a full-time engineer's attention, not zero. If the resulting payback period is still under 12-18 months, you have a number worth defending to a CFO. If it only works at 100% automation and zero ongoing cost, you have a pitch deck, not a business case.
Say a workflow costs ₹4 lakh a month in fully-loaded labor at 100% manual handling. A vendor pitches 90% automation and shows savings of ₹3.6 lakh a month against a one-time build cost of ₹15 lakh — an implied payback under five months, which is the kind of number that gets a project greenlit fast. Run the same numbers at a defensible 65% automation rate, with ₹25,000 a month in inference and hosting, ₹40,000 a month in exception-handling time at the now-higher per-case cost, and a ₹30,000 monthly allowance for monitoring: net monthly saving drops to roughly ₹1.6 lakh, and payback stretches to closer to nine to ten months. Still a good project — but a CFO who signed off on five months and finds out it's ten will trust the next number a lot less than one who was told nine to ten up front and it landed close to that.
This formula assumes you already know your build cost and your monitoring overhead — both of which are their own estimation problem. If you're scoping the build side, what an AI MVP actually costs to build breaks down where engineering time and inference spend land before a system ever reaches the ROI-measuring stage, and AI chatbot development cost in India does the same for the specific case of a support or sales assistant.
If you want that formula run against your actual workflow before you commit budget, that scoping conversation is where our AI automation engagements start.
A build vs buy framework for AI features — where buying wins, where a thin wrapper is genuinely correct, and the three conditions that justify building AI infrastructure yourself.
Where the money goes when you build an AI product MVP — engineering time, model inference, data preparation, evaluation — and which scope decisions move the total most.
Most SaaS products need one or two AI features done well, not nine done shallowly. A filter for telling which pitched features are load-bearing and which are decoration nobody uses.