The economics of renting AI at 200 employees

At twenty employees, AI is a productivity assist. The bill fits on a corporate card. At two thousand employees, AI is a platform decision, with procurement, security review, and a line in next year's plan. The interesting companies live in the middle — two hundred to two thousand employees, mid-market, with enough scale to feel the cost but not enough to treat it as a rounding error. That is the band Blue Abraham works in, and it is the band where the build-versus-rent conversation actually tips.

This essay is a plain economic treatment of that conversation. I have intentionally retired the "tax" framing I used in earlier drafts of this site. It was dramatic and it was not quite right. What is actually going on is more prosaic, more honest, and more useful as a basis for decisions.

Three slopes, not one number

The first thing to notice about AI spend in a mid-market company is that it does not arrive on a single invoice. It arrives on at least three.

The first slope is seat licenses. Copilot-style assistants at a per-user monthly rate, usually bundled into an existing productivity suite. Five hundred seats at thirty euros per month is a hundred and eighty thousand euros a year. Two thousand seats at the same rate is seven hundred and twenty thousand. The slope is roughly linear in headcount, it is easy to understand, and it is the hardest of the three to reason about because the value is diffuse. Some of those seats genuinely save time; some replace a Google search; some get ignored. The procurement conversation treats them as a benefit; the finance conversation treats them as a cost centre; the truth sits in between and moves around with how well the feature catches on.

The second slope is API passthrough. Every AI feature the company ships on its own surfaces — a summariser inside the product, a classifier inside a pipeline, a retrieval layer inside a search — consumes tokens against a frontier API or an open-weights endpoint on managed infrastructure. The slope here is linear in usage, not in headcount. For a mid-market company with a single deployed AI feature at modest use, it might be tens of thousands of euros a year. For a company with three to five shipped features at reasonable traffic, it is comfortably six figures, and visibly growing.

The third slope is productized features. These are vendor AI products that attach to existing workflows — legal review tools, contract extraction, sales enablement, support summarisation. They are usually priced as platform fees plus per-seat plus per-document, and they are the slope most likely to grow fastest in the first year because the value is concrete and the sales motion is well-practiced. A single such tool at mid-market scale is easily in the low six figures, and most companies end up with more than one.

Add those three, and a mid-market company's all-in AI spend, eighteen months into the current cycle, is almost always larger than the CTO thinks it is. I have walked into engagements where the answer to "what are we spending on AI" is a number that covers the API bill and none of the seat licenses or vendor platforms; the true figure, once finance has pulled the invoices together, is typically two to four times higher.

What the first slope really buys

Before I get to the build-versus-rent decision, it is worth being specific about what each slope is paying for.

The seat license slope is paying for ambient productivity. A developer using an inline code assistant. A marketer using a rewriter. A contract reviewer using an in-editor suggester. The value is real and the slope is hard to cut without a visible employee-experience cost. There is no interesting build-versus-rent decision here. The answer is rent, negotiate the price, and audit usage.

The API passthrough slope is paying for model access inside features the company owns. This is where the architecture matters. Renting the model is fine; that is what the API is for. The question is everything around it: who owns the prompts, who owns the context engine that selects the right material, who owns the eval harness that tells the company whether the feature is getting better or worse. If those layers live in the vendor's wrapper, the company is effectively renting the feature, not the model. The API passthrough line on the invoice understates what the company is actually committing to.

The productized features slope is paying for time-to-value. A vendor product that works well is genuinely faster than building. The cost of speed is that the vendor's system becomes the source of truth for a part of the company's process, and the proprietary data running through it ends up shaped by the vendor's representation of the domain. That trade is often worth it on day one. It is almost always re-evaluated on day seven hundred, when the company has accumulated two years of records, prompts, and decisions inside a system it does not control.

Where the curves actually cross

The honest build-versus-rent analysis at mid-market scale is not "build is cheaper than rent." It is: for each distinct AI capability the company depends on, there is a volume, a time horizon, and a strategic weight at which the curves cross.

Volume is the easy part. A token factory has a relatively fixed cost profile — engineering to build, modest infrastructure to run, ongoing eval maintenance. A rented solution is roughly linear in use. Below some usage threshold, rent is cheaper, full stop. Above it, build is cheaper, and the gap widens with volume.

Time horizon is where intuition fails. A three-year planning horizon makes build look much better than a twelve-month horizon does. The build cost is front-loaded; the rent cost is compounding. Most mid-market companies do their AI business case on a twelve-month lens, which systematically underweights the build option. The fix is not to change the lens but to acknowledge that a system the company depends on is not a one-year system, and to run the build case on its actual horizon.

Strategic weight is the part that does not show up on an invoice at all. For a given AI capability, the question is whether the outputs, the prompts, the evals, and the proprietary interactions feed a moat the company is trying to build, or whether they feed a commodity the company is trying to consume. If the capability is commodity — transcription, translation, generic summarisation — rent it and move on. If it is proprietary — contract extraction specific to your contracts, technical retrieval specific to your documentation, decision support specific to your customers — the strategic weight argues for owning the architecture, regardless of where the volume and horizon curves happen to cross this quarter.

The usual answer at mid-market is a portfolio. Some slopes are rented, some are built. The interesting architecture question is the second one: which parts are built, and in what shape.

What a mid-market architecture review usually finds

I run architecture reviews as one-to-three-week engagements, fixed-price, with a written output. In the mid-market band, a few patterns recur often enough to be worth stating in advance.

The first is that the company is already spending more on AI than it thinks, and the split is wrong. The seat license slope is usually under-questioned; the API passthrough slope is usually under-instrumented; the productized features slope is usually the largest number and the least examined. The first thing the review produces is an honest map of those three slopes. Often that map alone is the reason the engagement pays for itself.

The second is that the company has committed to a vendor wrapper on a capability that should have been owned. The failure mode here is specific: a team shipped an AI feature quickly by wrapping a vendor, it worked, and a year later the wrapper is the feature's architecture. Prompts, evals, retrieval — all lives inside the vendor. The cost of moving is substantial. The cost of not moving, and watching the wrapper change pricing, change quality, or get acquired, is larger. The review names this honestly and scopes the migration.

The third is that the company has over-built on a capability that should have been rented. This is less common and more embarrassing. A team built a bespoke pipeline on an AI capability that is now commodity, the pipeline is expensive to maintain, and a two-line vendor call would do the same job at a small fraction of the cost. The review names this too, and recommends unwinding.

The fourth is that the eval harness does not exist. Very nearly every time. The review's first recommendation in that case is not to migrate anything; it is to build the harness, so that the next decision about any of these slopes can be made against numbers.

The three-year view

The reason the economics matter in this band specifically is that the decision window is short. At twenty employees, no one decision matters much; the company can re-architect in a weekend. At ten thousand employees, the architecture is already committed and the conversation is about managed migration. Between two hundred and two thousand, the architecture is being laid down now, for a time horizon of several years, with invoices that are visibly growing and procurement conversations that are visibly intensifying.

The three-year view is where a token factory starts to look like a capital structure decision rather than a line item. Building means moving part of the AI cost from operating expense, compounding with usage, to a front-loaded engineering investment and a smaller, bounded operating cost thereafter. Renting means keeping it all as operating expense, linear in use, at whatever price the vendor charges three years from now. Neither is correct in the abstract. The correct answer depends on which capabilities are proprietary, which are commodity, and how confident the company is about the volume on each slope.

What I will not do, in this essay or in an engagement, is pretend the build case is always right. It is not. There are capabilities, even at mid-market scale, where the honest answer is to rent, document the dependency, and move on. The point of an architecture review is not to recommend building; it is to make the decision legible. Legible decisions survive vendor pricing changes, model deprecations, and the eventual arrival of a different CTO. Illegible decisions become someone else's migration.

What to do this quarter

If a company in this band is reading this and wants a concrete starting move, it is this: pull the three slopes together into one number, for real, with finance looking over the shoulder. Then pick the single largest line item and ask whether that capability is proprietary or commodity. If it is proprietary, scope an architecture review on it specifically. If it is commodity, renegotiate.

That is enough of a first step to change the conversation. The rest follows from there — sometimes toward a build, sometimes toward a sharper rent, sometimes toward a hybrid. The economics do not force a single answer. They just force a better-informed one, and at mid-market scale, that is most of the work.