The data for 2026, and why build vs. buy is the second question.
The committee approved the GenAI budget in forty minutes. There was a use case, a productivity projection, competitive urgency, and the CEO was desperate to post on LinkedIn that the company is now AI-native (because that sells well to the board and the market). Nobody asked for details.
At the same meeting, the proposal to allocate two engineers to platform work was postponed until the next quarter. It wasn't rejected. It was delayed, which is how infrastructure decisions usually die.
Six months later, the developers are generating code at a speed no one had ever seen before. And the company is delivering software at the same pace as always. No one knows how to measure quality or ROI.
I've spent the last ten years building internal platforms, much of that time before the term "platform engineering" even existed. I've seen this scene repeated in very different contexts, with one constant: the conversation about the platform almost always comes too late. It is framed as a technical decision when it's actually a capital allocation decision.
This text is for those who need to defend this capital.
You already have a platform.
The first thing to say in a conversation with the CFO or CEO is that the company isn't deciding whether it will have a platform. It already has one.
It exists as scripts only John Doe understands, a Slack channel where environment requirements are requested, a Terraform project that three teams copied and modified, a security checklist in a spreadsheet, and an approval process that lives in the head of someone who's been there for six years. This platform incurs costs, has an informal owner, experiences downtime, and carries debt. What it doesn't have is a budget line.
I call it an accidental platform. Not because it was built by accident, but because it never went through a conscious investment decision.
The data supporting this: Google's DORA 2025 research, based on responses from nearly 5,000 technology professionals, found that 90% of organizations already use an internal platform, and 76% have teams dedicated to it. Adoption is no longer the issue. Quality is.
The number that convinces the CFO.
The report State of DevOps: Platform Engineering Edition 2026, a study published by Puppet, precisely measures the difference between having AI and having well-developed AI. Among organizations with platform maturity, 73% say that this maturity supports AI outcomes, compared to 44% among less mature organizations.
The contrast becomes more stark in governance. Among platform-mature organizations, 79% report mature governance. Among immature organizations, the figure is 14%.
It's a category difference.
The same report shows that 66% of organizations already apply AI in infrastructure flows, but only 31% are actually able to operate autonomously. When there is a standardized internal platform, this number rises to 44%. And confidence in AI, which is what unlocks real adoption in a large company, reaches 92% in environments with a standardized platform, compared to 51% in environments where governance is improvised.
If you need a phrase to present to the committee: The platform isn't what comes after AI. It's what determines whether AI will work.
Why GenAI turned an old problem into an urgent matter.
For years, the argument in favor of the platform was developer productivity. It was a good argument, but it consistently lost out to product priorities because engineering productivity is difficult to translate into revenue on a CFO spreadsheet.
GenAI changed the framework for a specific reason: it created an agent that acts.
On May 26, 2026, Gartner published a forecast that should be included in every Platform business case: By 2027, 40% of companies will downgrade or disable autonomous AI agents due to governance gaps identified only after production incidents. Analyst Shiva Varma points to the root cause as the binary treatment of agent governance, either locked or fully trusted.
Read that sentence again with a corporate risk perspective. It's not a prediction that AI won't work. It's a prediction about companies discovering, in production, that they didn't know what the agents were allowed to do.
DORA describes the same phenomenon from the delivery side, using a precise term: downstream disorder. Individual gains in code-writing speed are swallowed up by bottlenecks in testing, security reviews, and deployment. Research from 2025 shows the distribution of change lead time. The situation remains difficult: 43.5% of teams still take more than a week between commit and production, and only 9.4% take less than an hour.
A developer who is 30% faster, within a system that takes 9 days to approve a deployment, produces exactly 0% acceleration for the business.
Where is the money?
An investment case that works with a CFO separates two types of gains because they have different degrees of confidence and should be defended differently.
The first is direct cash flow into the infrastructure. Here you have external ammunition. Broadcom’s Private Cloud Outlook 2026, a study based on blind research with 1,800 senior IT leaders in eight countries, found that 97% believe some of their public cloud spending is wasted, and 52% estimate that this waste exceeds 25% of their total cloud budget. In the same survey, cost surpassed security as the primary concern with the public cloud for the first time, and 62% of leaders said they were very or extremely concerned about the cost of AI infrastructure.
This is the number that opens the door. Cloud waste isn't a theory; it's a near-unanimous perception among those who manage the budget. A platform that does continuous right-sizing and puts cost guardrails in place at the time of provisioning; it attacks this at the source, not in the next month's report.
The second type of gain is the recovery of engineering capacity. It's larger and less tangible: developer time that currently goes to waiting and ticketing; platform and SRE time that currently go to repetitive manual tasks; security time that currently goes to reactive fixing. Support this block with numbers from your own company, not market ranges. Determine how many hours were dedicated to environment requests in the last quarter. Count the tickets. Measure the time between the request and delivery.
A case built with internal data survives the CFO's next question. A case built with vendor benchmarking does not.
Build or buy is the second question.
Here, I need to be transparent: I lead the Brazilian operation of a company that sells a platform. You should read what follows knowing this, and I should write knowing that you know.
The question I usually see first is always "build or buy". That's the wrong question to begin with because it assumes the company is starting from scratch, which is never the case. It's starting on an accidental platform that already costs money and has accumulated debt.
The right question is: In which part of this layer does our company have a real differentiation?
Building is a defensible decision when there's scale to justify a platform team treated as a product, with a roadmap and user base, and when there's a business constraint that no market product covers. Banks with very specific regulatory requirements sometimes fall into this category. Companies with tens of thousands of services, too. I've been on both sides of this table, and the honest version is that building works when the company accepts that the platform becomes a permanent internal product, with a permanent team.
The mistake I saw most often wasn't underestimating construction costs. It was underestimating the maintenance cost.
Construction has a completion date and is included in the project budget. Maintenance, however, never ends and disappears into payroll costs. Every year, someone needs to upgrade, audit broken integrations, revert changes made by the cloud provider, and support the new team that arrived with a different use case. This cost rarely appears on the spreadsheet that approved the "let's build" decision.
And there's a third option that almost no one considers: buying the governance layer and maintaining what already works underneath. Repository, pipeline, Terraform, observability… what's already running and what the team already masters continues to run. What you buy is the layer that ensures this entire set obeys the same policy, with the same auditing, applied equally to people and agents.
The warning sign
There is a simple test to determine if the accidental platform has already become passive.
Ask how long it takes a newly hired developer today to deploy a trivial change to production on their own, in a SECURE, AUDITABLE, and EFFICIENT way. Not the manager's estimate. The measured time.
If the answer comes in weeks or no one knows it, the company doesn't have a tool problem. It has an operational cost that is already being paid every month, distributed across the payroll, without ever having gone through investment approval.
Gartner projects that by 2026, 80% of large engineering organizations will have dedicated platform teams, compared to 45% in 2022. Most will get there. The difference will be between those who got there by choice and those who got there by accumulation.
The committee that approved GenAI in 40 minutes didn't make a mistake. It erred in treating the two decisions as if they were independent.
