What an Unused AI Feature Actually Costs

An AI feature that nobody uses is not free. It has three separate cost lines, only one of which stops when usage does, and the largest of the three is usually the one that is never written down. Here is how to total them with your own numbers, and what could have been known before the build started.

Three cost lines, not one

The usual accounting for an unadopted feature is engineering time, treated as sunk and therefore ignored. That undercounts badly, because two of the three lines keep running for as long as the feature exists.

The trap is that build cost is the only one visible at the moment the adoption failure becomes obvious, so the decision gets framed as “we already paid for it, leave it” when the actual question is whether the recurring lines are worth their recurring price.

Build cost, including the parts nobody counts

Engineering days are easy and usually the smaller half. The parts that go uncounted are the ones that were charged to some other budget:

• The evaluation set. Any AI feature that reached production responsibly has one, and building a real evaluation set is days of labelling, not hours.
• The review the feature triggered. A feature that sends customer text to a third party pulls in privacy review, a sub-processor disclosure, and often a contract amendment. That cost is attributable to the feature even when it lands on somebody else’s time sheet.
• The abstraction it forced. Frequently the first AI feature is what pays for the provider abstraction, the cost attribution and the guardrail layer. That share is genuinely recoverable by later features and should not be charged to this one — but only if a later feature actually arrives.

Run cost, which does not fall with usage

The intuition that an unused feature costs nothing to run comes from thinking of inference as the only variable. Inference is the line that does scale with usage; almost nothing else does.

• Monitoring and alerting cost the same whether the feature serves ten requests a day or ten thousand, and an unused feature is the one whose alerts get ignored first.
• Provider churn is fixed per integration. A model deprecation notice costs the same engineering attention for a feature with no users as for the flagship — see what a model release actually requires from your code.
• Security surface is fixed. A path that accepts untrusted text and forwards it to a model is in scope for prompt injection review at every audit, at zero usage.
• Support is worse than proportional, because a feature few people use is a feature nobody on the support side has practised on. That dynamic has its own page: the support load an AI feature creates.

A reasonable planning figure is that run cost splits into a fixed part and a variable part, and for a low-adoption feature the fixed part dominates completely. That is the sentence that turns the decision around: removing it recovers almost all of the run cost, whereas reducing its inference spend recovers almost none.

Removal cost, the line that traps teams

Removal cost is the only line that rises with time, and it rises for reasons that are invisible from outside the codebase.

1. Coupling accumulates. The logging schema, the billing categories and the dashboard were all extended to accommodate the feature. Each is now load-bearing for something else.
2. Data outlives the feature. Stored prompts, completions and embeddings carry retention obligations that do not end when the UI does. Deleting them is a project; erasure over model-adjacent data is harder than deleting rows.
3. Contracts name it. If the feature was disclosed to customers, in an agreement, in a data-processing addendum or in a security questionnaire, removing it is a communication exercise rather than a deploy.

The practical consequence: decide about a low-adoption feature early, because the cheapest removal is the one done before the second quarter of coupling. The decision procedure itself is in retiring an AI feature.

A worked total

Substitute your own figures; the structure is the point. Everything below is arithmetic on inputs you supply, not an observation about any particular product.

INPUTS you fill in
  build_days            engineer-days spent, including eval set and review
  day_rate              fully-loaded cost of one engineer-day
  requests_per_month    actual usage after the adoption failure
  cost_per_request      your measured average, input + output tokens
  fixed_run_hours       engineer-hours per month the feature obliges
                        (monitoring, upgrades, provider churn, audit)
  removal_days          estimate today; it rises roughly with coupling

ONE-OFF
  build_cost   = build_days * day_rate

MONTHLY, VARIABLE
  inference    = requests_per_month * cost_per_request

MONTHLY, FIXED
  toil         = fixed_run_hours * (day_rate / 8)

THE COMPARISON THAT MATTERS
  monthly_total       = inference + toil
  months_to_break_even_on_removal
                      = (removal_days * day_rate) / monthly_total

WORKED EXAMPLE (illustrative inputs, not a measurement)
  build_days 30, day_rate 600 -> build_cost 18,000
  requests_per_month 4,000 at cost_per_request 0.004 -> inference 16
  fixed_run_hours 6 -> toil 6 * 75 = 450
  monthly_total = 466, of which inference is 3.4%
  removal_days 4 -> 2,400 / 466 = 5.2 months to pay back removal

The illustrative case makes the general shape visible: inference is 3.4% of the ongoing cost, so every conversation about “making the feature cheaper” is a conversation about the wrong 3.4%. And removal pays back in about five months, which is short enough that deferring the decision by a quarter is itself the expensive choice.

The four signals available before you build

Adoption failures are rarely surprises in hindsight. Four signals exist before a line of code is written, and all four are cheap.

Making the decision once it has already failed

By the time adoption is visibly poor, the conversation is contaminated by the people who built it, the people who promised it and the people who are measured on it. Three moves make it decidable anyway.

1. Take build cost out of the discussion entirely. It is spent in every branch, so it is irrelevant to the choice. The only question on the table is whether the recurring cost buys more than spending the same effort elsewhere. Anyone arguing from “we already invested” is arguing about the past.
2. Set a decision date and a threshold in advance. “If weekly active use is below X on this date, we remove it”, agreed before the number is known. Deciding afterwards means arguing about the threshold rather than about the feature, and the threshold argument is unwinnable.
3. Offer three outcomes, not two. Keep, remove, and narrow. Narrowing — keeping the capability for the one segment that does use it, and removing the general entry point — is frequently the right answer and is almost never on the table, because the question was framed as a binary.

If the answer is removal, do it while removal is still cheap. The procedure is in retiring an AI feature, and the interface-level version of the same decision is in when to remove a chatbot.

One thing worth salvaging in every case: the evaluation set. It outlives the feature, it took days to build, and it is immediately reusable by whatever gets built instead. Deleting the feature and deleting its labelled data are two separate decisions and only one of them is obviously correct.