A CFO’s slide makes a simple claim: AI coding tools cost ₹4.7 crore a year, which is the same as sixteen engineers, so cut sixteen. The logic seems solid at first, but if you build the cost model step by step, you find that “sixteen” is not a fact about the technology. Depending on reasonable accounting assumptions—such as avoidability, governance level, or whether you include year-one costs—the same invoice can honestly equal anywhere from 9 to 24 people. Even a headcount chosen with good intentions doesn’t hold up over time: a moderate cut of 17 people looks fine for two years, then quietly turns into a five-year loss. The deeper cut that actually saves money comes with a modeled 15% drop in service quality. This article walks through the full cost model to show what’s really being decided when a board picks a headcount number that seems more precise than it is.
There are two reasons that slide deserves a closer look. First, if you build the cost model carefully, the “sixteen people” number is just one of several possible answers, and the differences have little to do with the AI itself. Second, even if a company gets the math right, it still operates in a competitive environment where, as recent economic research shows, everyone can end up worse off—even those who appear to win. These aren’t moral arguments against AI. They are simply what the numbers reveal when you examine them closely.
Part One: Building the real cost model, line by line
Imagine a typical Indian software company with 100 people: 65 engineers, 10 QA and test engineers, 8 DevOps/SRE/cloud engineers, 7 product and project managers, 5 UX/UI designers, and 5 engineering managers and architects. These numbers are just a template and won’t fit every company exactly. If you adjust the salary bands, the totals will change, but the logic remains the same.
A pure SaaS organisation, non-AI-enabled: what "cost" actually means
The first thing this model does right—something most quick estimates miss—is recognizing that an employee’s salary isn’t their total cost to the company. You also have to include things like provident fund, health insurance, recruitment and replacement costs, equipment, rent, admin, and training. This model uses a 1.385 multiplier to get the “fully loaded cost,” which is about 38.5% more than base pay. If you skip this step, you end up comparing an AI subscription to a salary that’s too low, making AI look cheaper than it really is.
With all these costs included, the 100-person team costs ₹31.27 crore a year, or about $3.47 million. Software engineers alone make up almost two-thirds of that, at ₹19.81 crore for 65 people.
Next, let’s turn that into an hourly rate and see how the hours are used. Assume there are 220 working days in a year, with 8 paid hours each day, and that 70% of that time is spent on real work, not admin, leave, or unproductive meetings. This gives the company about 123,200 productive hours per year, at a fully loaded cost of about ₹2,538 per productive hour, or about $28 per hour.
This is where the model becomes helpful. It doesn’t just give a number; it breaks down how each hour is actually spent:
Read that table slowly, because everything downstream depends on it. Only 35% of the year goes into building new things. The other 65% is the unglamorous work of keeping software that already exists alive, safe, and coherent — and long-run industry benchmarking suggests this maintenance share often runs even higher, 65–85% of total cost of ownership, in real organisations. AI coding tools are genuinely useful across a meaningful slice of this pie. But "the model writes code as well as an engineer" is a claim about roughly a third of the job, not the whole job. The other two-thirds involves judgment, accountability, and institutional memory — knowing why the billing service has that strange workaround in it — that a model doesn't carry from one session to the next.
AI-enabled SaaS organization
The model assumes AI billing for large language models as follows: 50 heavy users (doing complex coding) at $200 per month each, 25 moderate users at $100 per month each, and 25 light users at $20 per month each. This totals $156,000 a year, or ₹1.404 crore. Add in automated usage — CI/CD pipelines reviewing pull requests, bots sorting tickets, nightly evaluation jobs — estimated at 10% of individual spending, or about ₹0.14 crore. The total model spend is ₹1.544 crore a year. Keep that number in mind, because it will soon seem small.
Why the real bill is four times that. The LLM bill is ₹1.54 crore, but the full first-year program costs ₹6.19 crore. The LLM vendor receives only about 25 paise per rupee spent. Here's where the other 75 paise goes:
- A 3-person AI platform and governance team — ₹1.35 crore. The single largest line item in the entire program, bigger than the model bill itself. Someone has to own model routing and version pinning, issue and rotate API keys, set and enforce per-user spend caps, build integrations into your repositories and ticketing systems, run evaluation suites, and investigate why week-over-week accuracy quietly drops after a vendor's model update. If your company already runs a platform or DevEx function, this might be one incremental hire, not three — which is exactly the kind of line worth challenging against your own org chart before accepting it.
- Infrastructure and retrieval — ₹0.40 crore. This covers RAG (retrieval-augmented generation — searching your own code and docs first, then feeding the relevant pieces to the model rather than hoping it already knows your codebase) and the vector database that powers the search. It's a running system with compute, storage, and an index that goes stale the moment your code changes.
- Observability and evaluation — ₹0.25 crore. Logging what the model actually does, tracking cost and quality per user, and running recurring test suites so a silent model regression shows up on a dashboard rather than in a customer's inbox. Under metered billing, this line is the only thing that can eventually answer whether the $200-a-month seats ship proportionally more accepted work than the $100 ones.
- Security, privacy, audit, legal — ₹0.30 crore. Secret scanning, dependency and license review, access reviews, data-classification work, and legal time on residency and provenance questions.
- Knowledge-base maintenance — ₹0.25 crore. Retrieval is only as good as what it retrieves, and documentation rots the moment nobody's paid to keep it current.
- Training and contingency — ₹0.25 crore. Onboarding a hundred people to a genuinely new way of working, plus buffer for vendor support and surprises.
- An incident and rework reserve — ₹0.35 crore. Provisioned, not spent — held against the chance that generated code causes a production incident or security finding. A plan that assumes nothing will ever go wrong isn't a plan.
- A one-off first-year implementation cost — ₹1.50 crore. Connecting repositories and CI, configuring client tooling, classifying data, running the pilot, training staff. This is why the recurring annual figure (₹4.69 crore) is lower than the first-year figure (₹6.19 crore) — the migration cost disappears after year one.
The LLM itself costs ₹1.5 crore per year. Figuring out if it's actually helping — and handling problems when it isn't — costs another ₹3.2 crore. This changes where you should focus your negotiations. Companies often spend months trying to lower vendor token prices, which is only a small part of the bill, while higher costs, such as a platform team, a reserve fund, and an implementation program, are approved without much thought.
The same program, three honest sizes
Here's what the ₹3.15 crore "everything other than the LLM" figure hides if you take it at face value: it isn't a single fixed number the AI forces on you. It's a policy choice — a decision about how much control, oversight, and safety infrastructure a company builds around the AI it's using. The model gives you three honest versions of the exact same program, differing only in how much apparatus wraps around an identical AI deployment:
Walk through what each row is actually telling you, because the table only lands if you read it as a chain of cause and effect rather than three columns of numbers. The Lean option has one person handling model routing, key management, and integrations. The Base option includes three people, providing additional capacity for evaluation and monitoring. The Regulated option ( for firms working as Fintechs/Hospitals which are highly regulated) has five people, adding audit, isolation, and compliance oversight needed in regulated industries. The AI model, tools, usage, and 100 employees remain the same across all three cases — only the number of people managing the system changes, and that change cascades through every row below it.
This isn’t a suggestion to always choose the Lean option. Lean has a lower bar because it removes most of the evaluation and monitoring tools, which are the very things that help you prove if the AI is really working. That’s a real trade-off, not just a cost saving. And regulation isn’t just extra bureaucracy. Banks, hospitals, and defense contractors genuinely need audit trails, data isolation, and retention controls, because the alternative is failing to comply, not saving money.
The main point for the board is this: the AI vendor has much less control over your total cost than you do. Your choices about oversight, safety, and control have the biggest impact—more than token pricing or which model you use. So when someone says, “the AI costs us 16 people,” the real question isn’t “is that number right?” but “which scenario are we in, and did we choose it on purpose?”
So: how many people does that invoice actually equal?
Let's go through the math step by step, because seeing the numbers change is more convincing than just hearing that they do.
Step one — the naive calculation. Take the middle, Base-case configuration: a recurring program cost of ₹4.6944 crore. Divide that by what one average, fully loaded employee costs — ₹0.3127 crore a year:
₹4.6944 cr ÷ ₹0.3127 cr = 15.01 people → rounded up to 16
This is the number that appears on the CFO's slide.
Step two — a small correction. That naive calculation quietly double-counts something. If an employee leaves, the company isn't just saving their salary — it also stops paying for their slice of AI usage. Subtracting that ~₹1.54 lakh annual AI usage from the "cost per head saved" makes each head slightly cheaper to remove, nudging the number down:
₹4.6944 cr ÷ (₹0.3127 cr + ₹0.01544 cr) = 14.30 people → 15
Step three — a more realistic adjustment in the other direction. When someone leaves, the company doesn't stop paying all of their costs. Office rent, manager time, and bulk software licenses don't go away just because one person is gone. Accountants call the part of the cost that really disappears the avoidable cost, and it's usually about 80% of the total, not 100%. Using only that avoidable part pushes the number back up, higher than before:
₹4.6944 cr ÷ [(₹0.3127 cr × 80%) + ₹0.01544 cr] = 17.67 people → 18
Fold in the ₹1.50 crore one-off first-year implementation cost on top of that, and the year-one figure rounds up further to 19 (or as high as 24 at 80% avoidability including that first-year spend) — and that's still before accounting for severance, notice periods, or transition costs.
With three simple, reasonable adjustments — none of them a stretch — the same ₹4.69 crore invoice gave answers of 15, 16, and 18. Combined with the governance choice from the table above, the honest range is 9 to 24 people. The real lesson is that the break-even headcount is not a fixed fact about the technology. It changes based on which reasonable assumptions you use — governance, avoidability, timing — and none of these depend on what the AI can actually do.
There’s another, less obvious problem with even the most careful version of this number. All the calculations above answer “what is this invoice equal to in salaries?” but not “what is this invoice equal to in work?” These are not the same, and the difference matters. An AI model doesn’t get called at 2am, doesn’t defend past architecture decisions, doesn’t help a confused customer with a vague bug report, and doesn’t remember why a strange workaround exists. About 65% of an engineer’s year is spent on this kind of maintenance, judgment, and coordination, not just writing new features. So even if “this invoice equals 16 salaries” is accurate in terms of cost, it doesn’t mean the AI can do what 16 people do.
That’s why the real takeaway isn’t “replace engineers with AI.” It’s more specific, and less catchy: prove a real, quality-adjusted productivity gain of about 15 to 20 percent that holds up under checks for defects, security, and incidents. Only then should you turn that gain into something finance can use, like avoiding new hires, letting go of contractors, clearing a backlog, or earning new revenue with freed-up capacity.
Part Two: What five different cuts actually do to your cash
The break-even headcount tells you what the invoice is worth in salaries. It says nothing about what happens after you actually make the cut and let five years pass. For that, you need to run each staffing decision as a real cash-flow scenario — money in, money out, discounted for the fact that a rupee next year is worth less than a rupee today.
The model tests five staffing strategies against the identical AI deployment, from doing nothing to cutting more than a third of the delivery organisation:
Two of these are worth putting under a microscope, because they're the two a board is most likely to actually choose: Moderate looks like the "sensible middle path," and Aggressive is the one that shows up in a spreadsheet as a clear financial win.
Moderate — the cut that looks fine until year four. Cutting 17 people saves ₹5.21 crore a year against a (now smaller) AI bill of ₹4.43 crore. On paper, that's a margin. Run it as actual cash flow against doing nothing, and the margin turns out to be a mirage:
Read the middle three years like a heartbeat monitor, not a headline. Year 2 is +0.42 crore. Year 3 is +0.04 crore — a rounding error above zero. By Year 4 it's gone negative, and it keeps sliding through Year 5. Nothing dramatic happened at that point; the AI programme's costs simply grew by 8% a year as usage and vendor pricing rose, while the payroll savings from the people who were no longer there remained fixed. A cut that looked like it paid for itself in year two is, on a five-year view, a net loss of ₹6.02 crore in today's money — and it never recoups its cost. Seventeen people lost their jobs to fund a programme that, honestly measured over five years, cost the company more than doing nothing at all.
Aggressive — the cut that works, on the condition you accept what it costs. Cutting 35 people is a different story financially:
This one is unambiguously cash-positive from year two onward, pays back in about 28 months, and closes five years up ₹9.11 crore in NPV terms. If the only column a board reads is the cash column, Aggressive is the answer. But this is the same scenario the model expects to cut sustainable output by 15% — meaning the ₹9.11 crore isn't found money; it's the price of a service level the company has decided its customers will absorb. The cash flow proves the layoff was affordable. It doesn't prove it was safe, and the two are constantly conflated in board conversations that only look at the top line.
When you compare the two scenarios, the trap becomes clear: the option that feels moderate and defensible quietly loses money for five years, while the option that actually makes money is the one that is designed to reduce what customers receive. In this model, there is no scenario where cutting people pays off without some other cost. It’s always a trade-off between cash and output, and the “safe middle” option gets neither. Firing people based on an unproven productivity gain is a bigger risk of unfairness—to the employees who lose their jobs for a benefit that might never appear, and to the customers who end up with worse service.
Conclusion
Go back to the CFO's slide from the opening of this piece: "AI coding tools cost us ₹4.7 crore a year. Sixteen engineers cost the same. Cut sixteen." Part One and Part Two together tell you exactly why that sentence collapses the moment you press on it.
Part One showed that “sixteen” was never a fact about the technology. It was the result of choices that didn’t appear on the slide—like which salary you count, whether you build Lean or Regulated, whether you use 100% or 80% avoidability, and whether you include year-one implementation. If you run those same reasonable assumptions, the honest range is 9 to 24 people. The AI didn’t change; only the accounting did. A number that changes this much depending on who’s doing the math isn’t a fact—it’s a policy dressed up as one, and it deserves policy-level scrutiny, not the certainty of a fact.
Part Two showed that even a headcount chosen in good faith doesn’t behave the way a spreadsheet snapshot suggests. If you cut a moderate number—17 people—the deal looks fine for two years, but then turns into a five-year loss that no one planned for, because AI costs grow by 8% a year while payroll savings stay flat. If you cut deep enough to actually save cash—35 people—you get that win by accepting a modelled 15% cut in what customers receive. In this model, there was no scenario in which the company achieved savings, service, and certainty all at once. Something was always sacrificed; the only question was which one.
Sixteen people don’t lose their jobs because AI has proven it can do their work. They lose their jobs because a spreadsheet assumption landed on 16 instead of 9, and no one in the room asked which assumption led to that number.
This doesn’t happen in isolation. If the math above is tempting for one CFO, it’s tempting for every CFO who sees the same vendor pricing and productivity claims. When every company in an industry tries to save on headcount first, the logic that made sense for one company stops working for the industry as a whole. Customers left with a smaller, less experienced support and engineering team don’t care whose spreadsheet said 16 was the right number. A decision that seems rational for one company but is harmful for the industry isn’t a new problem created by AI, but AI has given an old problem a precise-looking number to hide behind.
The honest version of the CFO’s slide isn’t “cut sixteen.” It’s closer to: “We don’t yet know if this works. Here is what we’ll measure, here is the standard it has to meet, and here is what we’ve promised not to do until it meets that standard.” That may be a less satisfying sentence to present to a board, but it’s the only one the numbers in this article actually support.
Highlights
The "sixteen engineers" number is not a fact about AI — it's an accounting choice. Depending on the assumptions, the same ₹4.69 crore invoice can reasonably represent anywhere from 9 to 24 people.
The LLM bill is the smallest part of the AI programme — ₹1.54 crore, only 25% of the first-year cost. The rest funds a platform/governance team, infrastructure, observability, security/legal, knowledge-base upkeep, training, and a reserve fund.
Governance level, not vendor pricing, drives total cost: ₹2.79 crore (Lean) to ₹7.14 crore (Regulated) per year for the identical deployment, shifting the break-even headcount from 9 to 23.
"This invoice equals 16 salaries in cost" is not the same claim as "this invoice can do 16 people's work" — the exercise answers a cash-equivalence question, not a capability one.
Moderate cuts (17 people) look fine for two years, then quietly go negative — a five-year net loss of ₹6.02 crore in NPV terms, with no payback in sight.
Aggressive cuts (35 people) are genuinely cash-positive — +₹9.11 crore over five years — but only because the model expects a 15% drop in sustainable output.
No modelled scenario delivers savings, service quality, and certainty all at once.
The honest process is measurement before headcount: prove a real, quality-adjusted 15–20% productivity gain first, then convert it into avoided hiring, reduced contractor spend, or new revenue — not the reverse.
