AI in business operations is entering a new phase. The first wave of questions was about capability: can the model answer this, can an agent do that. The questions leaders ask now are colder:
- What is my ROI per dollar spent on LLM tokens?
- What is the cost per task, and is that worth it or overkill?
These are procurement questions, and they tend to arrive at exactly the moment a team is deciding whether to build an internal solution or buy one. Both paths can work. But the decision is usually made on the wrong evidence: a prototype that impressed people, instead of a unit economics number that survives production.
This post is the framework I walk through with leaders weighing that trade-off.
The V0 is not the product
It is relatively easy to build a V0 in-house using frontier models and their SDKs. A capable engineer, an API key, and a week of focus will produce a prototype that answers real questions against real data. The demo lands, and the case for building looks obvious.
Part of why the build case feels safe is that we price it like traditional software. A SaaS application, a UI on top of a database, can practically be vibe-coded these days. The build cost lands once, the marginal cost of serving one more user is close to zero, and maintenance is incremental. Those economics forgive a lot of estimation error.
AI solutions do not behave that way. Every task carries a recurring inference cost, and that cost scales with usage for as long as the system runs. An optimized AI solution, one that holds accuracy while keeping cost per task down, cannot be vibe-coded into existence. It takes evaluation infrastructure, prompt and routing design, caching, guardrails, and a team that re-validates all of it every time the model underneath changes. In this world the recurring AI cost, not the build cost, is the critical decision point.
| Cost structure | Traditional SaaS build | AI solution build |
|---|---|---|
| Build | Mostly one-time. A working app can be vibe-coded in weeks. | A real investment: evals, routing, guardrails, cost engineering. |
| Run | Roughly constant. One more user costs close to nothing. | Recurring. Every task burns tokens; the bill scales with usage. |
| Maintain | Incremental. Patch, upgrade, move on. | Continuous. Models change underneath; accuracy and cost need re-validation every time. |
| The question | Can we build it? | Can we build it optimized, how long will that take, and does it still make sense? |
If it’s a static SaaS tool, you can easily build it. An AI solution with recurring token costs? Think twice before building in-house. It’s a Pandora’s box.
So getting a prototype to work is very different from making it production-ready and economically viable. Production means accuracy targets, consistent answers, access control, an audit trail, and a monthly bill finance can live with. The road from V0 to that state is where three comfortable assumptions fall apart.
Three assumptions that do not survive production
- 1“We’ll switch to a cheaper model later.” A lower-tier model is not the same product. Accuracy and consistency drop, and the evaluation and prompt work needed to claw them back often costs more than the tokens saved.
- 2“We’ll optimize our way down.” You cannot vibe-code your way to a lower cost per task without giving up accuracy somewhere. Real cost reduction comes from architecture: scoped steps, caching, routing. Not from prompt tweaks.
- 3“Prices will keep falling fast enough.” Older model tiers get cheaper, but production systems keep getting rebuilt on the newest models, and newer frontier models have often cost more than the ones they replaced. Waiting is not a cost strategy.
None of these assumptions is unreasonable. They are just untested at V0, and each one hides a cost that only shows up at production volume. Which is why the useful first questions are not “can we build this” but “what will one task cost, at the accuracy we need, on the ten-thousandth run”, “how long will it take us to build it that optimized”, and “does it still make sense for us to build”.
Put a price on one question
Try asking a generic AI co-work tool: “What was my GMV in the Chicago region last week?” With the right integrations and skills, it may well produce an accurate answer. But look at what it did to get there: planned an approach, hunted for the right tables, wrote a query, checked its work, summarized. Depending on the implementation, that loop can cost $2 to $10 in tokens. For one number.
Now ask the follow-up every operator actually cares about: “Why did my GMV drop?” That is not one query, it is an investigation: regions, merchant cohorts, basket sizes, promo calendars, seasonality. An open-ended agent reasoning through all of it can consume most of a day’s LLM budget on a single why.
| The ask | Open-ended agent | Governed workflow |
|---|---|---|
| GMV in Chicago last week | Plans, finds tables, writes and checks a query. $2 to $10 per ask. | Runs a saved, validated query path. Cents per run. |
| Why did GMV drop? | Open-ended exploration. Can consume most of a day’s token budget. | A root-cause workflow, built and validated once, re-run for cents. |
| Same ask next week | Reasons from scratch again. Costs the same again, may answer differently. | The same trusted path, the same answer, every run logged. |
That is the pattern worth noticing. With an open-ended agent, you pay for the reasoning every single time, and you hope it reasons the same way twice. The economical version does the expensive thinking once and remembers it. That is what we built Cimba on: the next generation of model, purpose-built for operational workloads, adaptive, with optimized long-term and short-term memory. So a repeated ask costs a query, not a fresh investigation.
And because Cimba watches your data continuously, the “why did it drop” investigation usually starts before anyone asks. The signal surfaces on its own, root cause attached, as a Next Best Action routed to the person who can act on it.
This is not an R&D budget where teams compete to see who can spend more tokens.
The six questions that decide build vs buy
Whether you build or buy, the economics obey the same physics. Operational workflows and business decisions demand accuracy, precision, consistency, and clear ROI attribution. So put both options through the same questions, honestly, before writing the internal design doc or signing the vendor contract.
Ask these of the build plan and the vendor alike
- 1Cost per task. What does one task cost at the accuracy bar the business needs? Measure both together; a cheap wrong answer is not cheap.
- 2Model sensitivity. What happens to accuracy and cost when the underlying model changes tier or version? Who re-validates?
- 3Consistency. Does the same question produce the same answer on Tuesday as it did on Monday? Can you prove it?
- 4Governance. Who approved each action, what exactly ran, and can you show an auditor the trail without a war room?
- 5Attribution. Can you trace a block of spend to the outcome it produced, in dollars, per task and per action?
- 6Fully loaded cost. Engineering time, evaluation infrastructure, and permanent maintenance ownership, not just the token bill, against the vendor price.
Building can be the right call. If the workflow is core intellectual property, you have a team that will own evaluation and cost engineering permanently, and the volume justifies the investment, build. What does not work is treating the V0 as evidence that the production system will be cheap, or assuming the maintenance burden lands on nobody.
Buying earns its place on speed and on the parts that are invisible in a demo: governance, evaluation, cost discipline, attribution. For reference, teams launch a new governed workflow on Cimba in under a week, and Swiggy went from start to full rollout across 10 business units, with 2,200 account managers onboarded, in under 3 months.
ROI per task settles the argument
Cost per task is half the ledger. The other half is what the task returned, and that half is only knowable if every action is logged against the outcome it produced. Not hours saved, revenue you can attribute. Here is what one run looks like when both sides of the ledger exist:
gmv_dip_root_causeRun #14707:58:1207:58:4108:04:1508:11:0217:00:00One measured action is a data point. Hundreds of measured actions a week, each attributed, is how operations teams reach a real top-line number, on the order of +20% revenue per customer. That compounding is what you are actually procuring, whether you build it or buy it.
Before you sign either way
Run the six questions. Price the two GMV asks against your own stack. Ask the build team and the vendor for the same two numbers: cost per task at your accuracy bar, and ROI you can attribute per action. The option that can produce both numbers, and keep producing them as models change underneath, is the one that survives contact with production.
If you are in the middle of this trade-off and want to brainstorm, drop me a note. I have this conversation most weeks, and I am happy to have it before you commit budget rather than after.
Cimba is proactive AI for enterprise business and finance operations: governed workflows, every run logged, every outcome attributed. If you want to see the cost per task and the ROI ledger on your own data, book a demo.
Evaluating build vs buy?
Ask us the hard cost-per-task questions.