Unit economics is the AI question most pilots never ask

Most AI pilots answer the wrong question. They ask whether the model can produce a good answer. They almost never ask what one good answer costs, or what it brings in. So a pilot can look like a clear success and still lose money on every single request once it meets real traffic. The demo proves the thing works. It says nothing about whether the math works.

The question a demo cannot answer

A VP of engineering at a mid-market logistics company told me his pilot was the easiest sign-off he had ever gotten. The model classified shipping exceptions well, the stakeholders were happy, and everyone assumed the hard part was behind them. Then someone in finance asked a simple question. What does it cost us to process one exception, and what did the old way cost? Nobody had the number.

They went and found it. The AI path cost more per exception than the manual queue it was meant to replace, once they counted the model calls, the retries, and the human who still checked the low-confidence cases. The feature worked. It just did not pay. That is not a modeling failure. It is a unit-economics failure that the pilot was never designed to catch.

A CTO at a fintech described the same blind spot from the other side. Her team had shipped an AI feature that genuinely saved analyst time, and they could feel it. What they could not do was say how much one automated review cost versus one manual review. Without that pair of numbers, every conversation about scaling it was a guess.

Why the number hides until you scale

Unit economics stays invisible during a pilot for a mechanical reason. At pilot volume, the cost of any single request is a rounding error. You run the thing a few hundred times, the bill is small, and small bills do not force anyone to look. The number only becomes real when you multiply it by production traffic, and by then the feature is already built.

Real AI feature costs often run two to four times the initial estimate, and the gap almost always lives in the parts a pilot ignores. The retries. The human review. The verbose outputs. MIT’s 2025 State of AI in Business study found that about 95% of enterprise generative AI pilots deliver no measurable return, and a good share of those are not broken models. They are features that were never checked against a per-unit cost and a per-unit value.

What a unit-economics view forces you to count

A pilot that takes economics seriously measures four things before anyone talks about scaling:

Cost per unit of output. The full model spend for one completed task, including retries and any downstream calls, not the price of a single API request.
Value per unit of output. What one correct result is actually worth, in saved time or captured revenue, stated as a number you can defend.
The human residual. The share of cases a person still touches, and what that person costs, because it usually eats the savings.
The baseline it replaces. What the old way cost per unit, set before deployment, so the comparison is falsifiable later.

How we approach it at Density Labs

Our AI Opportunity Assessment is a fixed two-week engagement, priced at $2,500. When the question is whether a feature will pay, we build the unit-economics view first. We trace one completed task through to its true model cost, put a defensible value on the result, and set the baseline before anything ships. Sometimes the answer is that the feature works and the economics do not, which is a much cheaper thing to learn in two weeks than after a full build.

The pilot question is “can the model do this.” The production question is “does one unit of this make money.” Answer the second one first, and most of the expensive surprises never happen.