Platform engineering has moved past the buzzword phase. Most software organizations now have dedicated platform teams, and the tooling has caught up. But a growing number of these initiatives are stalling — not because the tools are bad, but because teams are solving the wrong problem.
They’re building portals when they need platforms.
The portal wave got one thing right
The first generation of Internal Developer Platforms focused on a real problem: developers couldn’t find anything. Services were scattered across wikis, Slack threads, and tribal knowledge. Backstage, the open-source framework created by Spotify and now a CNCF project, addressed this head-on with a centralized service catalog and plugin ecosystem.
And it worked — for discovery. Backstage remains the most widely adopted developer portal framework, with a community ecosystem of over 200 plugins covering everything from Kubernetes to CI/CD. Port followed with a no-code approach that let platform teams model their engineering topology without writing TypeScript. Cortex focused on engineering standards and scorecards. Each brought something valuable to the table.
That first wave proved that developer experience matters, that discoverability reduces cognitive load, and that a single pane of glass beats scattered documentation.
But here’s where most of them stop.
The last-mile problem
A developer finds a database service in the catalog. They click on it. And then… they open a Jira ticket. Or message someone on Slack. Or wait for a pull request to be reviewed in a GitOps repo they don’t have access to.
This is what industry analysts now call the “portal trap” — investing heavily in a front door that leads to the same manual provisioning workflows that existed before. The catalog looks great. The developer experience ends at the catalog.
The numbers reflect this gap. According to platformengineering.org’s 2026 survey, 45.3% of platform engineering teams cite developer adoption as their primary challenge, and 29.6% don’t measure success at all. The most common reason? The platform doesn’t actually do anything. It shows you what exists but can’t create what you need.
Backstage is particularly susceptible to this pattern because it’s a framework, not a finished product. Making it production-ready requires dedicated engineering effort — estimates from Roadie and independent analyses range from three to twelve engineers depending on scale, with ongoing maintenance for version upgrades, security patches, and plugin compatibility. For organizations with 500+ engineers and a well-resourced platform team, this investment can pay off. For everyone else, it often becomes the platform team’s own maintenance burden rather than a force multiplier.
Portal versus platform: the distinction that matters
The industry has started drawing a clear line between two concepts that were previously conflated:
A developer portal is the interface layer — catalog, documentation, visibility, and discovery. It answers “what do we have?”
A developer platform is the engine underneath — provisioning, multi-tenancy, service lifecycle, and automation. It answers “what can I get, right now, without asking anyone?”
The most effective platform engineering organizations treat these as separate architectural layers. The portal is the front door. The platform is the building behind it. You need both, but building only the front door and calling it a platform is why initiatives fail.
This isn’t a theoretical distinction. It shows up in concrete ways:
- Provisioning: Can a developer request a database and get one in seconds, or do they file a ticket?
- Multi-tenancy: Are teams truly isolated, or are they sharing namespaces with RBAC rules and hoping for the best?
- Service lifecycle: Does the platform manage updates, deprecation, and resource cleanup, or is that someone’s manual job?
- Extensibility: Can service owners plug in their own offerings, or is everything centrally managed by the platform team?
Tools like Humanitec recognized this gap early and built a “Platform Orchestrator” — a backend engine that dynamically generates environment-specific configurations. Kratix, from Syntasso, took a Kubernetes-native approach with its Promise-based framework. Both acknowledge that the portal layer isn’t enough.
What a platform actually needs
If a portal is a catalog, a platform is an operating system for developer services. It needs:
A provisioning engine. Not a link to Terraform docs — actual, automated provisioning that turns a developer’s request into a running resource. This means integration with infrastructure tools like Crossplane, Terraform, or cloud-native operators, abstracted behind a simple interface.
True multi-tenancy. Namespace-level isolation with RBAC rules is the Kubernetes equivalent of putting tape down the middle of a shared desk. It works until it doesn’t. A real platform provides workspace-level or cluster-level isolation where teams operate independently without stepping on each other.
A service catalog that provisions, not just lists. The catalog should be the interface through which developers actually create resources — not a directory that links to a runbook.
API-native architecture. Platform teams already know Kubernetes. A platform that requires learning a proprietary SDK, a new specification language, or a framework-specific plugin system adds cognitive load rather than reducing it. The best platforms work with the tools teams already use.
The AI dimension: platforms as agentic infrastructure
AI agents are already changing what platforms need to do. These systems — which autonomously plan and execute multi-step workflows — need well-structured APIs to operate. They need to discover available services, provision resources, and manage lifecycle, all programmatically.
This changes what we need from a platform in three ways:
Agents need APIs, not dashboards. A human can navigate a portal UI. An AI agent needs clean, well-documented, machine-readable APIs. Platforms built on standard Kubernetes APIs are inherently agent-ready — every operation accessible via kubectl is also accessible to any tool that speaks the Kubernetes API.
AI-assisted provisioning lowers the barrier. When a platform can accept a natural language description — “I need a PostgreSQL database with 100GB storage for my analytics team” — and generate the correct resource specification, the Kubernetes expertise barrier drops significantly. This isn’t replacing engineers; it’s making the platform accessible to a broader set of users.
AI workload management requires platform-level governance. As organizations deploy AI models internally, they need to control which teams access which models, manage compute allocation, and enforce compliance boundaries. A platform with proper multi-tenancy and RBAC becomes the governance layer for AI infrastructure — teams order a model, get an endpoint, and the platform handles isolation and access control.
The platforms that will matter in the agentic era aren’t the ones with the prettiest dashboards. They’re the ones with the most composable, API-driven architecture.
Where KDP fits
Kubermatic Developer Platform (KDP) was built with this portal-vs-platform distinction in mind. Rather than starting with a UI and working backward, KDP started with the infrastructure layer and worked up. KDP makes it easy to expose day-2 data to consumers, encouraging ownership and resolving the broken ownership problem.
Built on kcp, a CNCF Sandbox project. KDP’s foundation is open source and community-governed. kcp provides lightweight logical Kubernetes clusters called workspaces — each one a separate API server with true isolation at the control plane level, without the cost and complexity of spinning up full clusters. Actual workloads still run on service clusters managed by service providers, but tenants are completely invisible to each other at the API layer. This is multi-tenancy that goes beyond namespaces and RBAC rules.
Kubernetes APIs all the way down. There is no proprietary CLI and no TypeScript plugins to write. Service owners do work with KDP-specific custom resources like PublishedResource to define what they expose, but these are standard Kubernetes CRDs — not a new framework or specification language. Every operation in KDP — from browsing the service catalog to provisioning a database — works through standard Kubernetes APIs. If your team knows kubectl, they know KDP.
A service catalog that actually provisions. When a developer selects a service from the KDP catalog, they get a running resource — not a ticket. Service owners connect their clusters to KDP through the api-syncagent — a lightweight connector that handles bidirectional sync between the central control plane and distributed service clusters. Crossplane integration is built in, so cloud resources from AWS, GCP, or Azure can be exposed through the same catalog without custom glue code.
AI-native capabilities. KDP includes an AI assistant integrated into the dashboard that converts natural language requests into valid Kubernetes resource manifests, with server-side schema validation to catch errors before submission. But the AI story goes deeper than developer assistance. KDP’s architecture — API-driven, multi-tenant, with standardized service interfaces — makes it a natural governance layer for AI infrastructure itself. Platform teams can control model access per workspace, manage GPU compute boundaries, and provide self-service AI model provisioning through the same catalog that handles databases and storage. When your teams need access to an LLM endpoint, they request it from the catalog like any other service — the platform handles isolation, RBAC, and resource allocation.
Designed for service owners, not just consumers. Most portals are built for developers consuming services. KDP is equally built for the teams providing them. Service owners manage their own clusters and decide what to publish to the platform. The central platform team doesn’t become the bottleneck for every new service.
Complements portals, doesn’t replace them. If your organization has already invested in Backstage or Port as a developer-facing UI, KDP doesn’t ask you to throw that away. KDP operates at the platform layer — the provisioning, multi-tenancy, and service lifecycle engine that sits behind whatever portal your developers prefer. The portal is the front door; KDP is the building.
Questions to ask when evaluating your IDP
Whether you’re building, buying, or somewhere in between, these questions cut through the marketing:
Does it provision, or does it just catalog? If a developer still files a ticket after finding a service, you have a portal, not a platform.
What does multi-tenancy actually mean? Namespace + RBAC is not the same as workspace-level isolation. Ask how teams are separated and what happens when one team’s misconfiguration could affect another.
What APIs does it expose? Proprietary APIs mean vendor lock-in and integration overhead. Kubernetes-native APIs mean your existing tools, scripts, and automation work on day one.
Who maintains it? A framework you self-host means your platform team spends time maintaining the platform instead of building golden paths. A managed solution shifts that burden but may limit customization.
Is it agent-ready? As AI-driven automation becomes standard, your platform needs machine-readable APIs and programmatic access to everything. If it only works through a UI, it has an expiration date.
Can service owners self-serve? If adding a new service to the platform requires the central team to build a plugin or write integration code, the platform team becomes the bottleneck — the exact problem you were trying to solve.
The IDP market has matured enough that “we need a developer portal” is no longer a sufficient strategy. The question now is whether you’re building a front door or the building behind it.
