The internal developer platform concept enjoyed a sustained run of attention from roughly 2021 through 2024. Platform engineering teams expanded rapidly inside large engineering organisations, vendor marketing built up around the category, and the IDP became a recognisable architectural shorthand for how mature engineering functions ought to be organising their developer experience. The intensity of the conversation has moderated considerably over the past year. What remains is a more pragmatic and operationally useful version of the original idea.
The shift is not a retreat from internal developer platforms as a concept. It is a recalibration of what the platform team is actually for, how big it should be, and what success looks like over a multi-year horizon.
What the original ambition looked like
The high-ambition version of the platform engineering pitch positioned the internal developer platform as a comprehensive abstraction layer between application developers and the underlying infrastructure. The platform would provide self-service interfaces for environment provisioning, deployment, observability, service registry, secret management, and the dozens of other concerns that sit between code and production. Application teams would consume these capabilities through a coherent developer portal, freeing them from infrastructure concerns and dramatically improving delivery velocity.
The vision had genuine merit, and several large engineering organisations have built platforms that look broadly like this. It also produced a wave of platform team expansion that, in retrospect, was larger and more expensive than the actual developer-experience gains in most organisations justified. Platform teams of twenty, thirty, or fifty engineers became common in mid-sized engineering organisations that probably did not need a platform team of that size given their underlying complexity.
The hype-trough phase has been about correcting both the scope and the headcount.
What's settled out
A more realistic version of the platform engineering function has emerged from the recalibration, and it looks meaningfully different from the expansive earlier version.
Platform teams are smaller than they were eighteen months ago in most organisations that had built them up significantly. Some of the reduction has come from explicit headcount cuts during the broader engineering hiring contraction. Some has come from quieter rebalancing as platform engineers have moved back to product teams or to other engineering functions. The teams that remain are typically focused on a narrower set of capabilities than the original ambition described.
The scope has tightened in parallel. The most mature platform teams now focus on a defined set of high-impact capabilities, typically CI/CD, environment management, deployment, and a few cross-cutting concerns like service catalogue and observability conventions, rather than trying to be the single internal interface for every infrastructure concern. The narrower scope makes the platform team's value proposition clearer and its delivery commitments more realistic.
The portal-and-catalogue layer has also evolved. The first generation of internal developer portals often tried to expose everything an engineer might want to do through a single interface. The current generation is more comfortable being an entry point and a service catalogue rather than a comprehensive workspace, with deep links into the specialist tools that engineers actually spend most of their time in.
What the platform team's actual customer relationship looks like
The recalibration has also affected how platform teams think about their internal customer relationships. The earlier model often described application teams as platform consumers in a fairly one-directional sense, where the platform team built capabilities and the application teams used them. The current model is more bidirectional, with platform teams treating their internal users with something closer to product discipline.
This is visible in how the better platform teams now operate. They run defined feedback channels with application teams. They publish service levels for the capabilities they provide. They make explicit decisions about which capabilities are mature enough to be supported as platform features and which remain in beta. They retire features that are not being used, rather than maintaining them as background overhead.
That product discipline is more demanding than the earlier internal-tools-team posture, but it produces a platform that application teams actually want to use rather than tolerate. The platform teams that have made this shift tend to have measurably stronger adoption of their platform capabilities than those that have not.
Where vendor offerings sit now
The vendor market around internal developer platforms has matured in parallel with the recalibration of internal platform teams. The major hyperscaler IDP offerings have stabilised into reasonably well-defined product categories. Specialist vendors have settled into clearer niches: some focused on the portal and catalogue layer, others on deployment and environment management, others on developer experience telemetry and observability.
The buying pattern inside enterprises has become more discriminating as a result. The earlier pattern of trying to build the entire platform stack internally has given way to a more selective approach where the platform team buys vendor capabilities for the well-defined parts of the stack and builds internally only where the organisation has a genuinely specific need that the vendor market does not address.
This is a healthier division of labour than the earlier full-build approach, but it requires platform teams to make conscious architectural decisions about where the build-buy line sits. The teams that have done this well are typically those that started with the smallest defensible internal scope and expanded only where vendor offerings did not fit their requirements.
What the platform team should not do
The narrowing of platform team scope has also clarified what the platform team probably should not be responsible for, despite the temptation to absorb it. Several categories of work have proved consistently problematic when platform teams have tried to take them on.
End-to-end ownership of all infrastructure inside the engineering organisation is typically too broad. The platform team becomes accountable for capabilities it cannot meaningfully control, and the application teams lose the operational connection to their own production environments that they need to debug effectively.
Standardisation of all engineering practices across the organisation is similarly problematic. Some standardisation is genuinely useful, including common deployment patterns, consistent observability conventions, and a single approach to secrets management, but the platform team trying to be the standards owner for every engineering decision usually produces friction without proportional benefit.
Building bespoke developer tooling that the vendor market already covers is the third common failure mode. Platform teams that build their own CI pipelines, observability tooling, or environment management systems when reasonable vendor options exist usually find themselves maintaining infrastructure they did not need to own.
The teams that have avoided these failure modes are typically those that have been disciplined about defining what the platform team is for and what it is not, with explicit non-goals documented alongside the platform's roadmap.
What the next phase looks like
The platform engineering function is unlikely to disappear. The underlying need that drove the original concept, that application developers should not have to be infrastructure specialists and that consistent shared capabilities make engineering organisations more productive, has not gone away. What has changed is the realistic assessment of how large the platform team should be, how broad its scope should be, and what kind of product discipline it needs to operate with to actually deliver value.
The platform engineering teams that emerge from this recalibration phase are likely to be smaller, more focused, more operationally disciplined, and more honest about their costs and benefits than the expansive earlier version of the function. That is a less exciting story than the one the hype phase told, but it is the version that actually pays back in measurable developer experience improvements over a multi-year horizon. The next phase of the work is operational rather than architectural, and the platforms that mature through it will look more like well-run internal products than like the ambitious abstraction layers the earlier pitch described.
