By Vikas Sawarkar
CEO & Lead Architect
Work completed April to August 2026.
Every AI project reaches the same meeting. Somebody who has not been in any of the previous conversations opens a spreadsheet and asks what this costs and whether it is worth it.
My team at Aditi has sat in that meeting on both sides of the table, most recently on a document-automation build for a staffing client. I used to treat it as an obstacle between me and the interesting work. I now think it is the most useful hour in the project, and that the people who dread it dread it because they cannot answer the question that is actually being asked.
Because the question is not “what does it cost”. Everybody in the room knows roughly what it costs. The question is: when this is running, what will I be responsible for that I am not responsible for today?
That is a much harder question and it is the one that decides whether the project survives.
Where I have been wrong on cost
I have been getting one part of this consistently wrong, and I only noticed on a recent build.
We specified a self-hosted component for one part of the system, because the managed equivalent has a per-use price and the self-hosted version does not. On the spreadsheet, that is free. I have made that argument to clients more than once and I believed it.
It is not free. It is a line item that has been moved from the vendor’s invoice into the client’s operations, where it does not appear on any spreadsheet but is paid every month in somebody’s attention. Patching it, monitoring it, being the person who gets called when it is the reason something is down.
We ended up switching to the managed option during the build. The visible cost went up and the total cost went down, and the reason I can say that with any confidence is that the managed option’s cost appears on an invoice where the client can see it, argue with it, and forecast it.
I now put a line in the estimate called “things that are free because you will operate them yourself” and I put a number next to it. The number is a guess. Having the line there is what matters, because it turns an invisible cost into one the client can push back on.
The shape of the cost, which matters more than the amount
For a system like this one, the cost has a shape worth understanding, and the shape is stable even though the numbers are not.
Most of it is usage-based and small. Voice, avatar rendering, model calls, media minutes. It scales with how much you use it, which means it starts near zero and never surprises you upward without something visible having changed.
A little of it is fixed and boring. Hosting, storage, the database. Storage in particular is almost always a rounding error and almost always where somebody’s anxiety lands, because it is the only line they recognise from previous projects.
One component costs meaningfully more per minute than the others. In this system it is the avatar. Which is why it can be switched off mid-call, and why the mechanism that switches it off is the browser tearing down its connection rather than a server-side flag. If it had only flipped a database column, it would have demonstrated correctly and billed us for months.
And the largest cost does not appear on any of those lines. It is the human review that has to sit somewhere in the process, and the fact that somebody now owns a system that did not exist before.
The first three are what the spreadsheet asks about. The fourth is what the meeting is actually about.
The number that gets misrepresented
The pitch for automating a process like this is usually framed as time saved, and the time-saved number is real. A structured task that took a person a large part of an hour, repeated a few hundred times a year, is a lot of hours.
Here is where that framing goes wrong, and I have made this mistake in proposals.
If you present the saving as hours, the finance person converts hours to salary and asks who is leaving. That is a completely rational reading of what you said, and it is not what is happening.
Nobody leaves. In this system, a member of the HR team sits on every single call, the whole way through, exactly as before. The call still takes the same wall-clock time. On the crude measure, the saving is zero.
What changed is which minutes are demanding. Most of a structured onboarding call is a person narrating the same content for the fortieth time, which requires presence but not attention. Two or three minutes of it are a nervous new employee asking something that is not in any document, where a human being genuinely matters.
Before, those minutes were surrounded by forty minutes of narration and got whatever attention was left. Now they get all of it.
That is the return, and it is a real one. It is also not a number, which is why it is tempting to substitute the hours figure that is. Do not. A saving you have misdescribed will be measured the way you described it, and in twelve months somebody will ask why headcount has not fallen, and the honest answer will sound like a retreat.
Say the true thing at the start, even though it is harder to put in a cell.
Why this belongs in scoping, not in a review
Everything above sounds like a post-project reflection. It is not. It is the scoping conversation, and the reason to have it early is that it determines whether the project can be judged at all.
Most AI projects I see have no defined failure condition. Nobody has written down what “this did not work” would look like. A project without a failure condition cannot fail, which sounds like a comfortable position and is the opposite, because it also cannot succeed. It just runs until somebody’s patience or budget ends, and then it is quietly not talked about.
So the questions I now want answered before the build, not after:
What is this replacing, specifically? Not “manual effort”. Which task, done by whom, how often.
What will be true in six months if this worked? In terms the client would recognise, not in terms of the system.
What will be true if it did not? This is the one people resist, and it is the one that makes the rest usable.
Who owns it on the day it breaks? Every AI feature has an owner or it has a slow death. If nobody in the room is that person, the project has a problem no architecture fixes.
What are we paying for that will not appear on an invoice? The self-hosted trap, the review time, the attention.
None of these is a technical question, and all of them change the architecture. The ownership question in particular changes it a lot: a system with a named owner can degrade gracefully into human handling, and a system without one has to be built to never need a human, which is a far more expensive and less honest thing to attempt.
The version I give now
When I am asked what this costs, I answer in four parts. Usage costs, which are small and scale with use. Fixed costs, which are boring. The one expensive component and how it is contained. And the human time that does not go away but moves.
Then I say what the project would look like if it failed.
That last part has never once cost me an engagement, and it has twice changed the scope into something that was worth building. The meeting with the spreadsheet is not the sceptics’ meeting. It is the first meeting where anyone has asked what happens afterwards.