The platform engineering assembly tax is the cumulative cost of building and running a production platform from the open source ecosystem, not the tools themselves, which are free, but the time and expertise required to choose them, integrate them, and keep them running well. Oliver's recent post put numbers to it: 8–15 specialists, €1M–€2M annually, and a compounding maintenance burden that most teams underestimate.
What that post doesn't do (and what this one will) is break it apart. Because the assembly tax isn't one cost. It's three, and they're structurally different. They happen at different points in a platform's life, they affect different people, and they're invisible in different ways. Treating them as a single thing makes it harder to see where your team is actually losing time right now.
1. Evaluation paralysis: the cost before the build
The CNCF landscape currently contains over 200 projects. They span observability, security, networking, storage, runtime, and more. Most of them are genuinely good. Many overlap in ways that aren't obvious from the documentation. Almost none come with a clear recommendation for which combination works well together at production scale, with your team size, on your cloud provider.
So platform teams evaluate. They run proof-of-concepts. They read architecture decision records from other teams. They compare tools that can't really be compared on equal terms because they were built to solve slightly different versions of the same problem. And they do this while the project is notionally underway, which means the time cost is invisible, it doesn't appear in a project estimate, it appears later as slippage.
The 6–12 months to production that most teams experience doesn't start when they write code. It starts when evaluation does. And evaluation doesn't end cleanly — it bleeds into integration, which bleeds into re-evaluation when a new project release changes the calculus.
This is the phase that's hardest to defend in a retrospective, because at the time it felt like diligence.
2. Integration hell: the cost during the build
Each tool in the CNCF ecosystem was designed to solve one problem well. Very few were designed to be composed with dozens of other tools by a team of four engineers on a deadline.
The gap between "tool A is installed and working" and "tool A is working correctly alongside tools B, C, D, and E in a production environment, including under upgrade conditions" is where project estimates break down. Configuration choices made in one tool constrain choices in another. Network policies in one component interact in non-obvious ways with logging pipelines in another. Upgrade a component and you may find its assumptions about the environment no longer hold.
This is the phase teams usually anticipate. The problem is how they estimate it. The assumption is that integration is a finite task: do the work once, and it's done. The reality is that integration is ongoing maintenance. The platform doesn't stay integrated on its own. Every upstream release, every new component, every dependency update is a potential source of drift. And diagnosing and resolving that drift falls on the same team that was supposed to be building the internal developer platform, not maintaining the infrastructure underneath it.
The result is that platforms arrive in production later than planned, and cost more engineering time after they get there. Across 150+ production clusters over ten years, we've rarely seen a team that didn't find this phase more expensive than they modelled.
3. Hidden opportunity cost: the cost after the build
This is the component that never appears on a budget line, and it's the one that compounds indefinitely.
Once a platform is in production, it requires ongoing work: security patches, CVE tracking, Kubernetes upgrades, observability tuning, compliance validation. None of this is wasted: it's necessary. The question is who's doing it, and what they're not doing instead.
In our KubeCon EU survey this year, 143 platform professionals told us what they planned to focus on in the year ahead. Security and reliability came top. Cluster management and observability came third and fourth. These are maintenance priorities, the things you have to keep doing just to stay in place. They're the assembly tax showing up directly in roadmaps, consuming time that was nominally allocated to building capabilities that would actually move the business forward.
Across the customers we work with, the recoverable capacity often runs into the €800K range annually — the equivalent of several senior engineers' time, redirected from maintenance to work that moves the business forward.
The hidden opportunity cost is unique among the three components because it doesn't diminish as the platform matures. If anything, it grows: a more complex platform has more surface area to maintain, more upstream dependencies to track, more compliance requirements to absorb. Teams that don't make a deliberate decision about how much of this cost to carry tend to find it has quietly claimed half their capacity before anyone named it.
Three costs, three questions
The reason to separate these isn't taxonomy. It's diagnosis.
If your team is stuck in evaluation, months into tooling decisions with no clear production path, that's evaluation paralysis, and the fix is different from the others: more opinionated defaults, less comparison, a decision framework that values momentum over optimality.
If your platform is in production but upgrades take weeks and every change carries unexpected breakage risk, that's integration hell persisting into maintenance, and the fix is about reducing the integration surface: fewer custom decisions, more curated configurations with known compatibility.
If your strongest platform engineers are spending most of their time on maintenance rather than the internal developer platform you actually need them to build, that's opportunity cost, and it won't resolve until something changes about who carries the operational load.
Each of these has a different shape. The assembly tax label is useful because it names the pattern. But seeing which component is costing your team the most right now is what determines what to do about it.
If you want to think through where your team is in this, the TCO calculator on our website is a starting point, or let's chat.