The Internal Pricing Question
Platform engineering teams exist in a structurally awkward position: they create real value, but that value is hard to attribute. They are, by default, cost centers — their budget appears as overhead, their impact shows up in other teams’ productivity metrics, and when budget cuts come, they have no revenue line to point to.
This has led a growing number of organizations to experiment with internal pricing: charging product teams for platform services the same way they might pay a cloud provider. It sounds elegant in theory. In practice, it creates as many problems as it solves.
Why the Debate Exists
The core argument for internal charging is behavioral: engineers pay attention to cost when they pay for it. If compute and storage are free at the point of use, teams will over-provision, run redundant services, and make architecture decisions that ignore infrastructure economics. If they receive a bill, they start asking whether they actually need that eighth replica.
This is a real effect. FinOps practitioners have documented it repeatedly in cloud cost management: visibility into cost, even without hard caps, changes behavior. The question is whether the mechanism should be visibility or actual transfer pricing.
Three Models: Chargeback, Showback, Blended
Full chargeback creates genuine market dynamics. Business units receive actual invoices for platform consumption. They can choose to consume less, optimize their usage, or in extreme cases, build their own infrastructure. The upside is real cost accountability. The downside is gaming: teams optimize for the cost metric rather than the right architectural decision. I have seen teams self-host databases to avoid platform storage fees, then spend ten times as much in engineering hours managing those databases. The platform team’s apparent cost goes down; the company’s actual cost goes up.
Showback — providing visibility into what teams would be charged without actually transferring funds — builds cost awareness without creating the perverse incentives of real billing. Teams see their consumption, can make better architectural decisions, but do not have budget pressure that might lead to bad technical choices. The downside is that showback lacks teeth. Without actual consequences, some teams tune it out.
Blended approaches are what I see at mature organizations: showback for most services, with hard limits or genuine chargebacks for extreme consumers, quarterly cost review sessions with engineering leadership, and explicit unit economics (cost per request, cost per deployment) published internally.
What Actually Happens When You Charge
The behavioral effects of full chargeback are not always the ones you want:
- Teams under-use shared services that would be more efficient at scale because they optimize for their own cost center rather than total system cost
- Platform teams spend significant engineering time on billing infrastructure, cost attribution logic, and dispute resolution instead of improving the platform
- Small teams that cannot negotiate pricing end up paying proportionally more than large teams, creating equity problems
- Teams avoid using new platform capabilities because the cost is uncertain at adoption time
The FinOps parallel is instructive. Cloud providers have sophisticated tagging and attribution tools specifically because cost attribution at the resource level is genuinely hard. Building that internally for an internal platform is a meaningful engineering investment, and the ROI has to be measured against alternative uses of that investment.
What Best-Run Platform Teams Actually Do
After analyzing platform economics at several organizations of different sizes, the practices that generate the best outcomes are:
Showback with quarterly business reviews. Teams see cost data. Engineering leadership reviews it together. Outliers are discussed and addressed through conversation and architectural guidance, not automatic charges.
Unit cost transparency. Publish the cost per unit of each service: cost per deployment, cost per GB stored, cost per request served. This gives consuming teams the information they need to make architectural tradeoffs without the perverse incentives of hard charging.
Explicit SLAs with cost-per-SLA-tier pricing. If a team wants 99.99% uptime, they pay more than a team that can tolerate 99.9%. This is the most defensible form of internal charging because it creates genuine differentiation based on service level, not just consumption volume.
Platform P&L as a reporting construct, not a funding mechanism. Treat the platform like a business unit for reporting and accountability purposes, without actually transferring money between cost centers.
When Charging Actually Makes Sense
Full chargeback is most defensible in two scenarios: very large organizations where platform teams genuinely serve multiple distinct business units with different funding sources, and external-facing platforms where the platform team is selling capabilities that generate revenue. In both cases, the market dynamics argument is more legitimate because the organizational structure already creates genuine economic separation.
For most mid-size engineering organizations, the overhead of real chargeback exceeds its behavioral benefits. Showback with governance achieves most of the same cost-awareness outcomes at a fraction of the cost.