Explore why internal platforms struggle to scale and what cloud-first companies really need
In many organizations, developer speed is still constrained by access to SRE and DevOps teams. It’s a shared experience. Developers complain that everything takes too long. SREs are overloaded. DevOps tickets pile up. According to surveys, 78% of engineering teams wait a day or more for help, and for 16%, that wait can stretch to a week or beyond. This friction is costly, visible, and increasingly unacceptable in cloud-first environments.
To address this, many companies build or adopt Internal Developer Platforms (IDPs). The promise is compelling: faster delivery, standardized environments, reduced configuration drift, and fewer “works on my cluster” failures. In theory, IDPs give developers a paved road to production while shielding them from infrastructure complexity.
In practice, the story is more complicated.
Despite heavy investment, 94% of developers report dissatisfaction with self-service tools, and only 11% actively use them for self-service. These numbers aren’t a failure of intent — they’re a signal that IDPs become exponentially harder to sustain as they scale across teams, environments, and clouds.
And this is where many organizations underestimate what they are really signing up for.
An IDP is never “done.”
The moment it’s adopted, it becomes a living system that must evolve alongside cloud providers, security requirements, compliance regimes, cost models, and internal org changes.
To keep an IDP relevant, organizations quietly expand their infrastructure and platform teams:
Over time, the size and skill level of the platform team starts to rival core product engineering teams. And critically, these teams require top-tier infrastructure talent — the kind of engineers who understand distributed systems, cloud internals, policy engines, and automation at scale.
For digital-native or infrastructure-led companies, this may be an acceptable strategic bet.
For companies whose core business is not IT, it often isn’t.
As IDPs expand across teams and environments, familiar questions start surfacing:
These concerns sit outside the natural scope of developer-facing platforms, especially those built in-house or assembled from open-source components. The more freedom and automation you give developers, the more critical centralized governance becomes.
At that point, the IDP begins to morph into something else entirely.
IDPs exist to optimize developer experience. They abstract complexity, standardize workflows, and accelerate delivery.
CMPs exist to govern infrastructure at scale.
They handle cost controls, policy enforcement, security posture, auditability, and cross-cloud visibility.
The moment an IDP is expected to:
it is no longer “just” an IDP. It is becoming a DIY Cloud Management Platform — without being designed as one.
Most IDPs start small: scripts, templates, pipelines. Over time, responsibility accumulates:
Each addition feels incremental. Collectively, they turn the IDP into a fragile, tightly coupled control plane that is:
What works for one team or cloud account rarely generalizes cleanly across regions, providers, or regulatory contexts. The result is partial visibility, duplicated controls, and inconsistent policy enforcement — all while the platform team headcount keeps growing.
As developer friction drops, pressure shifts elsewhere.
Finance wants accurate cost attribution.
Security wants enforceable policies.
Risk teams want visibility into data residency and access.
Trying to satisfy these demands inside the IDP layer quickly becomes unsustainable. IDPs are optimized for flow, not oversight.
This is most visible in Day-2 operations. Today, only ~25% of engineers can self-serve Day-2 tasks through IDPs, leaving the rest dependent on platform, SRE, finance, and security teams. The original bottlenecks quietly return — just in a different form.
Both IDPs and CMPs are embedding AI, but for very different outcomes.
IDPs use AI to:
CMPs use AI to:
The real leverage appears when these layers work together. But that only works when the CMP has authoritative control over infrastructure and visibility across clouds. Without that foundation, AI-driven governance remains aspirational.
At the executive level, this isn’t a tooling debate — it’s an operating model decision.
Leadership doesn’t want to grow infrastructure teams indefinitely or compete for scarce platform talent just to keep internal tooling alive. They want developer speed without turning infrastructure governance into a bespoke engineering problem.
That’s why forward-looking organizations treat IDPs and CMPs as complementary layers:
In hybrid and multi-cloud environments, this alignment is not optional — it’s foundational.
We built the emma cloud management platform at the intersection of IDPs and CMPs because we kept seeing the same pattern: companies rebuilding governance, controls, and visibility inside platforms never designed to carry that weight.
emma delivers:
This allows organizations to offer a modern developer experience without committing to a permanently expanding platform.
IDPs aren’t replacing CMPs — and CMPs aren’t replacing IDPs.
What’s becoming clear is that building and sustaining an IDP is a long-term commitment, one that inflates infrastructure teams and demands elite talent. For companies whose competitive advantage is not infrastructure engineering, that’s often an unnecessary burden.
Organizations that recognize this early can stop reinventing the same controls, avoid scaling platform teams beyond reason, and adopt systems designed to govern cloud complexity at enterprise scale.
Speed is easy to promise.Sustainable control is hard to build — and that’s exactly why it shouldn’t be built twice.
