Pricing a Product With No Price

An internal platform has no revenue, no list price, and no customer who can leave. It still consumes real engineering investment, and somebody eventually has to justify that. Nobody hands you a P&L. You build the case yourself, or you lose the funding to a team with a louder sponsor.

Here is how ours evolved, including the two measures we had to throw away.

Two measures we threw away

We started by counting sensitive assets protected. It was the obvious number, it went up and to the right, and it worked for about a year. Then it stopped meaning anything. Once the count passed a few thousand, the difference between a hundred assets and ten thousand said nothing about whether we were creating value. We were counting rows in our own database and presenting it as impact.

So we changed it, and moved to queries running under a fine-grained policy. Better, because a query is somebody actually doing something, and the number scaled with real use rather than with our own ingestion. That one lasted longer.

Eventually it also stopped discriminating, and we moved to financial impact, which we had to construct from nothing.

Building the model

The model had two dimensions.

• Cost avoidance. What it would cost each adopting team to build the equivalent capability themselves — the role-based access control, the integrations into their systems, the audit and compliance surface — computed from implementation size, engineer count and elapsed time, then multiplied across adoptions. Not what we thought it was worth. What they would otherwise have had to spend.
• Productivity savings. Approval overhead, access-request cycles, and the elimination of a months-long manual change process that ran every single time an organizational hierarchy moved.

Then the step that mattered most: we took it to Finance to be challenged rather than publishing our own homework. They pushed on the assumptions, we revised, and what came out the other side had somebody else's name on the review.

The result landed in the high triple-digit millions of dollars. But the number I found more useful in a room full of engineering leaders was the same result expressed in the only currency they actually budget in: roughly <ENGINEER-YEARS> engineer-years that no team had to spend building their own version of this.

Dollars persuade a finance partner. Engineer-years persuade the person deciding what their org works on next quarter. It is the same model, divided by a different denominator, and I wish I had computed both from the start.

Change the measure when it stops discriminating

The number is the least interesting part of this. The exercise is what I would pass on.

A cost-avoidance model is structurally a value-based pricing model.

"What would it cost you to build this yourself, to this standard?" is exactly how enterprise infrastructure gets priced, because the buyer's alternative is always to build it. Every serious infrastructure vendor is running some version of that calculation to set a list price. I ran it rigorously and then priced the result at zero, because the product was internal. The analysis is the same analysis.

Which is worth knowing if you have spent your career on internal platforms and worry that you have never touched pricing. You may have done the underlying work without ever calling it that.

The general rule underneath all of it: change the measure the moment it stops discriminating. A metric that everyone likes, that always goes up, and that no decision ever turns on has quietly become a vanity number. It is doing reputational work, not analytical work. The uncomfortable version of the test is to ask what number, if it moved the wrong way, would make you kill something. If there isn't one, you are not measuring.

Changing a metric is politically expensive, because the old one is usually flattering and the new one usually is not, at least at first. Ours got smaller every time we changed it. That is the cost of measuring something real.

Most internal platforms never do this exercise at all. They report activity, they feel productive, and then one planning cycle they cannot answer a question a finance partner asks in thirty seconds. Build the model before somebody asks for it.