When we started doing platform work more than ten years ago, nobody called it “platform engineering.” We were just trying to make it easier for people to run software in production without losing their weekends.
A lot has changed since then. Kubernetes matured, the CNCF ecosystem exploded, and suddenly every enterprise has a slide about “internal developer platforms.” But one thing hasn’t changed: The sheer amount of work it takes to keep a production platform running once you’ve assembled it.
We’ve started calling this the platform assembly tax. Not the cost of building your platform, but the ongoing cost of keeping it alive, healthy, and compliant. In our experience, it’s the thing most teams massively underestimate.
Assembled, Not Designed
Most companies don’t buy a platform. They assemble one. You start with Kubernetes, add observability tooling, layer in security, connect a CNI for networking, and bolt on a developer portal. Each choice makes sense on its own.
But by the time you’re done, you have a platform that took six to twelve months before anything felt stable, a team that quietly grew to handle it, and a maintenance burden that shows no sign of shrinking. The CNCF landscape alone now hosts roughly 200 projects, with over 300,000 contributors and an ecosystem that touches nearly every layer of the stack. The options are extraordinary. The integration challenge is just as extraordinary.
The real issue is what happens after day one. Upgrades. CVE monitoring across dozens of open source components. Dependency chains between your ingress controller, your observability stack, your policy engine, and whatever your compliance team just asked for. Keeping all of that working together, continuously, across multiple clusters, while your developers just want to ship code.
The Tax is Paid in Time
Here’s the thing that gets lost in most platform discussions: The assembly tax is ultimately a time tax.
It’s not really about money, at least not directly. It’s about where your best people spend their hours. Every week a senior engineer spends chasing an upgrade conflict or debugging a Helm chart interaction is a week they didn’t spend helping a product team design a better system, or thinking about how to make the next hundred deployments safer and faster.
The industry numbers tell the same story. According to Google’s recent platform engineering research, organizations that co-manage platforms with external partners allocate roughly 47% of developer time to innovation and experimentation, compared to 38% for those managing everything internally. That gap sounds modest in percentage terms, but applied across a team of twenty or fifty engineers over a year, it adds up fast.
Gartner estimates that 80% of large software organizations will have platform teams by the end of 2026. CNCF’s latest report found that cloud native adoption has reached 15.6 million developers globally. The ecosystem is maturing. But maturity doesn’t automatically mean simplicity. Often, it means more components to evaluate, more integrations to maintain, more surface area to secure.
It’s Compounding, Not Stabilizing
You’d think this would be getting easier by now. In some ways, it’s getting harder.
Regulations like NIS 2 and the EU AI Act are adding new compliance requirements that platform teams are expected to absorb. Every new regulation means another set of controls, another audit surface, another thing to keep running correctly across all your environments. And AI workloads are landing on infrastructure that was never designed for them. GPU scheduling, token-level cost tracking, model serving across clusters, often without any additional headcount on the platform side.
The result is that the assembly tax compounds. Every layer you add increases the interaction surface. Every interaction surface increases the maintenance burden. And that burden is paid in the one resource you can’t buy more of: the time and attention of people who understand the system.
Does AI Reduce the Tax?
This is the question we get asked most often, and the honest answer is: the jury is still out.
AI-assisted development can speed up building, and it can reduce certain kinds of mistakes. But the hard part of platform engineering was never writing the code. It’s understanding the interactions between complex systems, validating that an upgrade in one component doesn’t quietly break three others, and making sure your security posture holds across all of it. Speed without validation is just faster failure.
We don’t know yet how much AI will change this. Anyone who tells you they do is selling something.
Open Source Isn’t Free
There’s a related misconception worth addressing: the idea that open source is free.
It’s free to download, yes. It is not free to operate. The time your team spends tracking upstream releases, monitoring vulnerability disclosures, testing upgrades, and contributing back to projects they depend on. That time has a real cost. Many organizations don’t account for it because, frankly, they don’t value their own team’s time correctly.
This isn’t an argument against open source. We’re deep believers in open source and in the communities around CNCF projects. But believing in open source means being honest about what it actually takes to run it well in production, at scale, over years. The question isn’t whether open source is valuable. It obviously is. The question is whether your organization is accounting for the full cost of operating it.
Questions Worth Bringing to Amsterdam
If you’re heading to KubeCon EU, here are some questions worth sitting with, whether you’re asking them of your own team or of any vendor in the solutions showcase:
How quickly can you push a critical security update across all your clusters? If a new compliance requirement lands tomorrow, how much of your platform needs to change? What does your disaster recovery actually look like, not on the slide, but in practice? How much of your platform team’s time goes to maintenance versus enabling developers? And if you needed to change a core component, could you do it without rebuilding from scratch?
These aren’t gotcha questions. They’re the questions that reveal whether your platform is an asset or a liability. And most organizations don’t ask them until something breaks.
The Real Measure
Platform engineering is a way of working, not a thing you buy. There’s no box you plug in that makes this go away. But there are real, honest choices about how much undifferentiated heavy lifting you want to do yourself versus relying on curated, well-integrated components from the community, from vendors, or from a combination of both.
The goal isn’t to eliminate platform teams. It’s to free them from re-solving the same problems everyone else is also re-solving, so they can focus on the work that’s actually unique to their organization. Helping teams design better systems. Making smarter trade-offs. Enabling experiments instead of blocking them.
The real measure of a platform isn’t how many tools it includes. It’s how much time it gives back to the people who use it.
If you’re dealing with this at your organization, I’d love to hear how you’re thinking about it. Find me at KubeCon, or just reach out.