Platform Funding Model
How internal platform work is paid for, which determines what the platform optimises for and whether it survives a budget cycle.
The funding mechanism shapes platform behaviour more than any technical decision, and it is usually inherited rather than chosen.
Central funding from an engineering budget with a mandate to serve is the model that works best in practice. The platform is judged on adoption and on consuming teams' outcomes, teams consume freely, and the platform team can invest in things whose benefit is diffuse. Its weakness is that demand is unpriced, so the platform can be pulled in every direction by whoever asks loudest, and it needs strong product management to hold a roadmap.
Chargeback, where teams pay for consumption, creates cost awareness and reliably produces gaming: teams avoid the platform to avoid the charge, build shadow alternatives, and optimise for the chargeback metric rather than for good engineering. It also makes the platform reluctant to decommission anything that generates revenue.
Project funding is the model that kills platforms. Funded to build, then disbanded, leaving a capability with no owner that decays into legacy within two years.
The practical recommendation: fund centrally, report showback so teams see what they consume without being billed for it, and measure the platform on adoption and on the delivery metrics of the teams it serves. That combination gives cost visibility without the perverse incentives, and it gives the platform a defensible case at budget time.