Infrastructure decisions that determine your AI unit economics

Unit economics is the cost of one more of whatever your feature produces: one more summary, one more classification, one more resolved ticket. For an AI feature, that per-unit cost is set mostly by infrastructure decisions made early, before anyone was thinking about money. By the time volume arrives and the per-unit cost starts to matter, the choices that determine it have already been made. Which is why a contract-summary feature can cost about $180 a month at two hundred contracts and $14,400 a month at eight thousand, and get there in six months. The slope was set at design time, not discovered at scale.

Build versus buy is a unit-economics decision

The clearest infrastructure lever is build versus buy, and it flips depending on scale. A product manager at a large search and ads company explained why his teams build their own support tooling instead of paying for the established platforms. “Sometimes the requirements are so unique at our scale that it makes more sense to build your own tool than work with third-party companies.” At their volume, per-seat pricing on a bought system loses to a first-party build. But that is a scale call, not a universal one. He was explicit that some teams still use the bought tools, because below a certain volume the build never pays back.

That is the trap in both directions. Buy when you should build, and your per-unit cost carries a vendor margin forever. Build when you should buy, and you carry the cost of operating infrastructure you did not need. Unit economics is the number that tells you which side of the line you are on, and it depends entirely on your volume.

The volume where the case becomes undeniable

Sometimes scale makes the infrastructure decision for you. A founder who served as a portfolio technology leader across a large software group watched AI change the unit economics of support directly. At one billion-dollar company, AI “made L1 support obsolete.” That was not a story about a model. It was a story about volume: first-line support is high-frequency, repetitive work, exactly where a per-outcome cost of near zero beats a per-outcome cost of a human every time. The infrastructure decision to automate that layer was justified by the unit economics of doing it thousands of times, not by any single interaction.

The pattern is worth holding onto. AI’s cost advantage is not evenly distributed. It shows up hardest in high-volume, repetitive work, and the infrastructure you build to serve that work is where your unit economics are won or lost.

The decisions that set the slope

The infrastructure choices that most shape per-unit cost tend to be:

Build versus buy. Vendor margin versus operating cost, decided by your real volume.
Caching and reuse. Whether identical or similar requests recompute or return a stored result.
Pipeline shape. How much work each unit triggers upstream before the model ever runs.
Batching. Whether you process one at a time at retail cost or in batches at a discount.

How we approach it at Density Labs

Our AI Readiness Assessment is a fixed two week engagement, priced at $2,500. We model the unit economics of your feature at real production volume, then trace them back to the infrastructure choices that set them: what you build versus buy, what you cache, how much work each unit triggers. The goal is to make the decisions that determine your cost slope while they are still decisions, not after the slope has already been drawn.

The model does not set your unit economics. The architecture around it does. Decide it on purpose.