From strategic bet to internal developer platform cost center
The internal developer platform that once signalled modern engineering now often looks like overhead. Many organisations quietly admit their shiny idp has turned into an internal developer platform cost center, with platform teams growing faster than developer adoption. When the platform team becomes the largest engineering group per capita, you have a problem.
Look first at adoption, because Humanitec’s 2024 State of Platform Engineering report shows only 31 % of organisations with a platform team report more than 50 % developer adoption (section on adoption benchmarks, figure on “Platform adoption by developer population”, page 18). If your internal developer portal or broader developer platform has flat or declining daily active developers, you are funding a product that the development teams no longer treat as a golden path. An internal developer platform that behaves like a cost center usually hides behind vanity metrics like number of services onboarded instead of measuring real software development flow.
The second warning sign is rising total cost of ownership for the idp while business outcomes stall. By year three, many organisations see internal platform TCO reach around 1.6 times the year one cost, as infrastructure, cloud usage, and platform engineering salaries compound, according to internal TCO analyses cited in the same Humanitec report (TCO modelling section, pages 26–28) and follow up case studies from early adopters. When the platform budget grows while lead time and change failure rate stay flat, the label of developer portal cost center is deserved.
Third, watch the custom portal backlog, because a swelling queue of bespoke features is a classic anti pattern. When developers ask for product-like capabilities in the developer portal that mirror existing tools, the platform engineers are effectively rebuilding commercial software inside the internal portal. That is how developer portals become products on top of other products, rather than a thin service catalog and access control layer.
Fourth, security and compliance work can quietly dominate the platform team roadmap. If every new control, policy, or access control rule is implemented only inside the idp, you create a parallel governance universe that is expensive to maintain. Over time, the platform engineering group becomes a bottleneck for security changes instead of a multiplier for engineering teams.
The fifth sign is fragmentation, when multiple developer platforms and developer portals coexist without a clear owner. Some organisations run a homegrown portal, a Backstage instance, and a vendor platform idp from Red Hat or another provider, each with its own service catalog and infrastructure abstractions. At that point, the internal platform is not a single product but a collection of tools that collectively behave like a cost center and dilute platform engineering ROI.
Rescue patterns before you write off the platform
Once you recognise the internal developer platform cost center dynamics, the first move is not always shutdown. A sharper scope for the idp can turn a sprawling developer platform into a focused layer that standardises software development workflows without owning every tool. Think of the platform team as curating golden paths rather than building a monolithic portal that replaces existing services.
Rescoping starts with ruthless clarity about which developer experience problems the platform team actually owns. Many successful engineering teams limit their platform engineering mandate to deployment, infrastructure, and environment management, leaving test tooling and analytics to other teams. In those cases, the idp becomes a thin orchestration layer over cloud infrastructure, not a full stack of overlapping tools.
The second rescue pattern is to resell the platform internally with hard ROI numbers. Product and delivery leaders respond when you connect idps to measurable outcomes like reduced lead time, fewer failed deployments, or lower infrastructure cost per service. Linking platform usage to rework and quality metrics, such as those discussed in the analysis of rework rate as a fifth DORA metric, helps reposition the idp as an investment rather than a cost.
Third, consider replatforming the developer portal layer onto a maintained open source foundation like Backstage. Many organisations treat Backstage as the second platform on top of the first, but used correctly it can replace a custom portal and simplify the service catalog and access control story. The key is to avoid rebuilding every internal tool inside Backstage and instead integrate existing services through lightweight plugins.
Another rescue move is to align platform engineering with an agnostic approach to business software choices. When the platform team focuses on consistent interfaces and contracts rather than enforcing a single vendor stack, you reduce lock in and keep the internal developer platform cost center from expanding unchecked. This is where guidance on an agnostic approach in business software becomes directly relevant to platform teams.
Finally, reset governance so that the platform team is accountable for clear best practices and service level objectives. Tie platform engineers’ goals to developer satisfaction, platform adoption, and time to onboard a new service into the service catalog, not just to infrastructure uptime. When the platform team behaves like a product team with explicit customers, the internal developer platform cost center can move back toward being a strategic asset. A European fintech highlighted in Humanitec’s 2024 case studies cut platform TCO growth in half by narrowing scope to deployment workflows and measuring developer NPS quarterly.
When sunsetting the idp is the right business decision
Sometimes the most rational move is to retire the idp and accept that the internal developer platform cost center experiment has run its course. The clearest signal is when fewer than half of developers use the platform for day to day software development, despite repeated engagement efforts. In that scenario, the platform team is effectively running a niche tool with enterprise level infrastructure cost.
Another trigger is when platform teams cannot articulate a differentiated value proposition versus managed cloud services. If your internal developer platform mainly wraps basic cloud deployment scripts and a generic portal, you are competing with every vendor that offers a developer platform as a service. At that point, platform engineers are better redeployed into product teams or reliability roles where their infrastructure expertise directly supports revenue.
Sunsetting does not mean throwing away the institutional knowledge embedded in the idp. Start by extracting the golden paths, runbooks, and best practices that the platform team codified into templates, pipelines, and access control policies. Those artefacts can be moved into documentation, lightweight tooling, or a smaller developer portal that focuses only on the service catalog and discovery.
A graceful exit also requires a clear migration plan for development teams that still rely on the platform. Map every critical service to its underlying infrastructure and tools, then provide a supported path to native cloud workflows or a new platform idp. The goal is to preserve the cycle time gains while eliminating the centralised portal and its growing maintenance cost.
Platform Engineering Day at KubeCon highlighted that many organisations over rotated on platform engineering without a strong product mindset. The retrospective analysis in what Platform Engineering Day at KubeCon actually changed shows how some platform teams shifted toward smaller, composable tools instead of one massive developer platform. Those stories underline that shutting down an idp can be a step toward healthier engineering, not a failure. One retail company profiled in the KubeCon recap reduced platform spend by 40 % within a year of decommissioning its homegrown portal and moving teams to managed cloud services plus a minimal service catalog.
As you unwind the internal platform, keep a small cross functional team to steward shared tooling and security baselines. This team can maintain minimal developer portals, manage access control, and curate a lean service catalog without owning a full idp. The result is a lighter internal developer footprint that still supports engineering teams without behaving like a cost center.
A decision tree for product and delivery leaders
For product and delivery managers, the internal developer platform cost center debate is ultimately a portfolio allocation question. You are deciding whether the platform team is the best use of scarce engineering capacity compared with direct feature development. A simple decision tree can turn a heated argument about tools into a structured conversation about ROI and risk.
Start with adoption, asking whether more than half of developers use the idp for their daily software development workflows. If the answer is yes and trend lines are positive, you probably have a viable developer platform that deserves further investment in developer experience and automation. If adoption is low or shrinking, move to the next branch and examine cost versus measurable outcomes.
On the cost branch, compare the full platform engineering spend, including infrastructure, cloud, and salaries, against improvements in delivery metrics. If the idp has not improved lead time, deployment frequency, or incident recovery, you are likely funding an internal developer platform cost center. In that case, either rescope the platform team to a narrower mandate or plan for a structured sunset.
The next branch focuses on strategic fit with your technology direction and vendor landscape. If your organisation is standardising on a vendor like Red Hat for infrastructure and developer tools, a heavy custom idp may duplicate capabilities that the vendor platform already provides. When the internal platform team spends most of its time integrating open source components that mirror commercial services, the opportunity cost becomes hard to justify.
Finally, assess whether the platform team operates with a true product mindset, engaging developers as customers and iterating on feedback. Platform teams that run regular research with development teams, measure developer experience, and maintain clear roadmaps are more likely to avoid the cost center trap. Those that only react to tickets and build one off tools for individual teams will struggle to justify their platform idp over time.
The decision tree does not give you an easy answer, but it forces clarity about trade offs. In the end, platforms are products, and products with no users do not deserve a roadmap. The winning move is to treat every internal developer initiative as a product that must earn its place in the engineering portfolio, not the keynote demo, but the third quarter in production.
Key figures on internal developer platforms and cost
- Only 31 % of organisations with a dedicated platform team report more than 50 % adoption of their internal developer platform among developers, according to Humanitec’s State of Platform Engineering report (2024 edition, adoption benchmarks section, page 18), highlighting how many idps risk becoming cost centers rather than shared products.
- Average total cost of ownership for an internal developer platform at year three reaches around 1.6 times the year one cost, once infrastructure, cloud services, and platform engineering salaries are included, which means platform teams must deliver compounding value just to break even.
- Three of the most cited cost center signals for idps are flat or declining developer adoption, growing platform team headcount, and an expanding custom portal feature backlog, based on CNCF Platform Working Group anti pattern discussions and early adopter case studies.
- Backstage based developer portals show a split pattern in production use, where some organisations report faster onboarding and better service catalog visibility, while others effectively run Backstage as a second platform on top of an existing idp, doubling maintenance cost without proportional gains.
- Humanitec and KubeCon retrospectives both emphasise that platform teams which treat their developer platform as a product with clear customers and measurable outcomes are significantly more likely to avoid the internal developer platform cost center trap over the medium term.