Platform Engineering in Practice: Building Internal Developer Platforms

Platform engineering has moved from trend to practice. CNCF’s 2025 survey found 82% of container users run Kubernetes in production, yet a CNCF and SlashData survey of cloud-native developers found only 28% of organizations have a dedicated platform team. The two figures come from surveys with different scopes and populations, so the gap between them is an illustrative signal, not evidence that most teams run modern infrastructure without an internal platform. This guide covers what an internal developer platform (IDP) is, why teams build one, how to staff it, and how to introduce it incrementally.

The Problem an IDP Solves

An IDP is an integrated collection of capabilities offered as a product: self-service APIs, tools, services, and golden paths that reduce developer cognitive load. The CNCF Platforms White Paper lists five reasons to build one: reduce cognitive load on product teams, improve reliability by dedicating experts to configuration, accelerate delivery by reusing shared tooling, reduce security and regulatory risk by governing capabilities, and control cloud costs while keeping a consistent user experience.

Teams without a platform reinvent the same pipeline, the same provisioning path, and the same monitoring stack. The result is duplicated effort, inconsistent security, and slow onboarding. A few platform teams serving many product teams multiplies their impact.

DORA’s 2024 report adds an important qualification: IDPs improve individual productivity, team performance, and organizational performance, but can also decrease change stability and throughput if implemented carelessly. The goal is developer independence, not a new bottleneck.

Platform as a Product

The CNCF white paper lists seven attributes of a successful platform:

1. Platform as a product — serve the most common use cases across teams, prioritizing breadth over single-team niches.
2. User experience — consistent interfaces across GUI, API, CLI, IDE, and portal.
3. Documentation and onboarding — docs and templates that form the golden path bundle.
4. Self-service — developers request and receive capabilities autonomously.
5. Reduced cognitive load — implementation details are encapsulated; users should not operate the services.
6. Optional and composable — teams may use parts of the platform or leave it entirely.
7. Secure by default — compliance and validation follow organizational standards.

A product mindset matters as much as the tooling. DORA recommends assigning a product manager for developer experience, mapping critical user journeys (spinning up a new service, debugging a production issue), and building a strategic roadmap from developer needs. A portal, CLI, API, and templates are the interface of the platform; treat them with the same care as a customer product.

Team and Operating Model

Platform teams are responsible for the interfaces and experiences — portals, APIs, documentation, templates, and CLIs — not necessarily for running compute, network, or storage. The CNCF white paper gives them three jobs: research user requirements and plan the feature roadmap, evangelize the platform’s value, and manage the interfaces. Team Topologies frames this as a platform team creating capabilities that many stream-aligned teams consume with little overhead.

Adoption is still forming. The CNCF and SlashData Q1 2026 Technology Radar found 41% of organizations use multi-team collaboration for platform work, while only 28% have a dedicated team. DORA’s platform engineering capability page reports far broader adoption: 90% of organizations use an internal developer platform and 76% have dedicated platform teams. The two surveys measure different populations, but both point the same direction: platform work is normalizing, and a dedicated, centrally funded team is the mature model.

The Investment aspect of the CNCF Platform Engineering Maturity Model describes the progression: voluntary tiger teams (Provisional), a dedicated centrally funded team (Operational), product management with a roadmap and chargeback (Scalable), and an ecosystem where specialists extend the platform (Optimizing). A widely cited Gartner prediction expected 80% of large software engineering organizations to establish platform teams by 2026, up from 45% in 2022 — a forecast, not a measurement.

Golden Paths and Self-Service

The golden path is the opinionated and supported route to a common outcome. Spotify, which popularized the term, defines it as the path to “build something” — a backend service, a website, a data pipeline — supported by step-by-step tutorials. The point is to eliminate rumour-driven development: teams follow a tested route instead of assembling tools from blog posts and hallway conversations.

A golden path is a reusable supply chain workflow for building, scanning, testing, deploying, and observing an application, delivered with an initial project template and documentation. Self-service means a developer can request a database and receive its locator and credentials by running a CLI command or filling out a web form — no ticket, no waiting.

Backstage, Spotify’s open-source developer portal, is the best-known example of surfacing golden paths in a software catalog with TechDocs. Per CNCF’s project page, it is an incubating project — not graduated — with thousands of contributors and an Excellent CNCF health score.

Escape hatches matter. The CNCF white paper lists optional and composable as an attribute: teams may use parts of the platform or leave it, but leaving the supported path means giving up the same support level.

Architecture and Tooling Choices

The platform should be the thinnest viable layer over managed providers and open-source building blocks. The CNCF white paper’s capability domains map directly to mature open-source tools:

• Developer portals: Backstage, Skooner
• Provisioning and APIs: Kubernetes, Crossplane, Helm, KubeVela
• Delivery and GitOps: Argo, Flux, Keptn, Flagger
• Build and test: Tekton, Buildpacks, ko
• Observability: OpenTelemetry, Prometheus, Jaeger, Grafana
• Identity and secrets: Keycloak, Dex, cert-manager, External Secrets
• Security and policy: Falco, OPA, Kyverno, in-toto

The Q1 2026 Technology Radar puts Helm (94% four- or five-star maturity), Backstage, and kro in Adopt for application delivery, with Argo CD, Buildpacks, GitHub Actions (91% would recommend), and Jenkins in Adopt for workflow automation. For security, cert-manager (87% four- or five-star), Keycloak, and OPA are in Adopt. The same radar notes that 35% of organizations integrate AI workloads through hybrid platforms — a signal that platform design needs to absorb new workload types.

Vendor lock-in is a design choice, not an accident. Reference architectures exist — platformengineering.org publishes a widely used IDP reference architecture, and AWS’s prescriptive guidance covers building one on its cloud — but the platform layer should stay thin and portable. Microsoft’s platform engineering guide makes the same point: use building blocks from multiple vendors and focus your custom investment on the glue that creates unique value.

Security and Compliance Guardrails

Secure by default is one of the CNCF attributes. Guardrails should live in the golden path, not in manual review: templates embed policy, scanning, and identity defaults that apply across the covered workflows. Enforcement is only as broad as the platform’s scope — teams outside it, or paths with explicit exceptions, are not covered automatically.

The radar’s security findings reflect this pattern: cert-manager for certificates, Keycloak for identity, OPA for policy, with supply-chain tools like in-toto and Sigstore still maturing. Governance embedded in templates and capabilities automates and enforces the covered controls on the supported path, and because policy, scanning, and identity checks run through the platform, they can be audited. Compliance still depends on what the platform covers, what exceptions teams are granted, and what the underlying providers enforce.

Measuring Success: Observability and Developer Experience

The CNCF white paper groups platform metrics into three categories: user satisfaction and productivity (active users, retention, NPS, SPACE), organizational efficiency (request-to-fulfillment latency, time from onboarding to first code change), and product delivery (DORA metrics: deployment frequency, lead time for changes, time to restore service, change failure rate).

DORA’s balanced scorecard adds DevEx surveys (CSAT or NPS), the H.E.A.R.T. framework for adoption and retention, and task success: the efficiency and effectiveness of completing key workflows. Notably, the platform capability most correlated with a positive developer experience is giving clear feedback on the outcome of tasks.

The DX Core 4 framework (Speed, Effectiveness, Quality, Impact) combines DORA, SPACE, and DevEx into one model worth adopting as a framing — treat its published outcome percentages as vendor marketing, not independent evidence. The maturity model warns about Goodhart’s Law: when a measure becomes a target, it ceases to be a good measure. Measure to learn, not to judge.

An Incremental Adoption Roadmap

The CNCF Maturity Model assesses five aspects — investment, adoption, interfaces, operations, measurement — independently. Each level of maturity costs more in funding and people’s time, so the highest level is not automatically the goal. As Martin Fowler puts it in the model, the value of an assessment is the list of things to work on, not the level itself.

1. Pick one golden path. Choose the most common workflow — often service deployment — and build just enough to make that journey demonstrably better.
2. Partner with a small number of engaged teams. The white paper suggests starting with frequently required, undifferentiated capabilities like pipelines, databases, and observability.
3. Measure adoption and feedback. Track active users, request-to-fulfillment latency, and task success; iterate on the journey.
4. Design for extension. Expose clear APIs and a contribution model so other teams add tools and services.
5. Expect a J-curve. DORA notes that platform initiatives often follow a J-curve: initial performance gains, then a dip in performance as complexity rises, before recovering and stabilizing at a higher level; plan for the dip.

Culture is often the real constraint. CNCF’s 2025 survey found 47% of respondents cite cultural change with development teams as the top blocker — ahead of any technology choice.

Common Pitfalls and Mitigations

DORA’s platform engineering guidance identifies five anti-patterns:

1. Build it and they will come — building on assumptions without user research. Mitigate with research and partner teams.
2. Ivory tower — a central team dictates rigid standards without collaboration, pushing developers toward shadow IT. Mitigate by co-designing with teams.
3. Ticket-ops trap — the platform team becomes a reactive vending machine instead of enabling self-service. Mitigate by investing in self-service.
4. Big bang release — building everything before shipping anything; needs change while you build. Mitigate by releasing an MVP golden path early.
5. Golden cage — rigid one-size-fits-all constraints that ignore diverse needs, such as data science versus mobile. Mitigate with enabling constraints and escape hatches.

Two structural risks deserve attention. First, the CNCF white paper notes that platforms fail when they are not treated as products: top-down mandates create resistance, and platform teams seen as cost centers struggle for funding. Include product managers from the start and tie the platform to value streams. Second, DORA’s 2024 research found that IDPs can reduce change stability and throughput; guard against that by focusing on developer independence and measuring a balanced scorecard.

Start With One Golden Path

You do not need a large platform organization to begin. Standardize one deployment path, treat the platform as a product, and expand from what developers actually adopt. The 28% dedicated-team figure and the 90% adoption figure describe the same trend from different angles: platform engineering is trending toward becoming the standard way to run software, and the teams that start small, measure honestly, and keep the platform thin will be the ones it helps most.

Sources: CNCF Annual Cloud Native Survey 2025, CNCF Platforms White Paper, CNCF and SlashData Q1 2026 Technology Radar, DORA Platform Engineering Capability, Spotify on Golden Paths, CNCF Platform Engineering Maturity Model, Gartner: Top Strategic Technology Trends in Software Engineering for 2024, Backstage | CNCF, platformengineering.org: Reference Architecture of an IDP on AWS, AWS Prescriptive Guidance: Building an internal developer platform on AWS, Microsoft Learn: Platform engineering guide, DX: Measuring developer productivity with the DX Core 4