Internal Developer Portals (IDPs) are being sold as the go-to solution for engineering teams, a one-stop shop for service catalogs, ownership tracking, and team performance scorecards. But let’s face it: the current crop of IDPs is not built for today’s developers.

If we strip away the marketing hype, many of these tools function more like portals — a window into service ownership and status — than actual developer platforms. It’s time to rethink IDPs not as “portals” but as “hubs” that actively route information and workflows, reducing developers’ toil rather than creating another layer of friction.

IDPs are portals that display service information to developers, but that’s where the utility often ends. Focusing on service catalogs, ownership, and health checks might benefit platform teams, but this feels like an overhead with minimal value for developers. Developers would review this information if investigating an outage, but they often meet feature deadlines and debug product issues.

Why Portals Fall Short

By their nature, portals are passive. They allow developers to see what’s happening but don’t let them take meaningful action. If your IDP is just another place to look at dashboards, check service ownership, and perform administrative work, it’s doing little to improve productivity. It may be doing more harm by introducing additional cognitive load, yet another dashboard in an ever-growing landscape of tools for developers.

Worse, most of these tools come with a producer-consumer problem: platform teams rely on developers to keep service information up to date, but developers don’t directly benefit from maintaining it. It’s a two-sided network of sorts, but with an imbalance that leads to stale data, creating what we often call Zombie Tools — systems that exist but are underutilized or ignored by the very people they’re meant to serve

Rather than considering IDPs as portals, we should conceptualize them as *hubs*. A hub is more than a window to view data — it’s a dynamic system where workflows are centralized and actions are triggered. Developers need tools that not only give them visibility but also let them act — whether that’s triggering a deployment, performing a code review, or tracking down the origin of a failing test.

The IPP (Internal Platform Portal) Dilemma

Another common pitfall is mistaking IDPs for true developer portals when, in reality, they are Internal Platform Portals (IPPs). These tools often serve platform teams rather than developers, emphasizing service management, health checks, and performance scorecards. They are often presented as benchmarks, with no feedback mechanism to help teams improve.

IDPs promise to empower developers, but they often end up as tools that platform teams love and developers tolerate — if they use them. The solution? Build IDPs that put developer workflows at the center. If developers can’t find day-to-day value, like tracking tickets, reviewing pull requests, or pushing feature flags, the portal is another layer of complexity.

A hot trend in IDPs is the integration of scorecards, frameworks that track service health and readiness. While useful for high-level insights, this begs the question: Are we just reinventing developer productivity tracking software under a new guise?

While platform teams might see value in these tools, engineering leaders must be careful not to over-index on scorecards as metrics for developer performance. Scorecards should empower teams by providing clear, actionable insights, such as where processes are bogged down, and not become a hidden monitoring tool.

How To Turn IDPs Into Developer Hubs

The biggest flaw of today’s IDPs is that they often feel like solutions searching for a problem. To be truly valuable, they must focus on what matters most to developers — reducing friction in their daily work.

A “hub” approach would mean integrating tools that developers care about:

• Code reviews: Simplify the process of reviewing and merging pull requests. Build better standards with code review SLOs, break down changes into smaller diffs, and track actionable code reviews.
• Work tracking systems: Provide visibility and quick access to tasks and blockers, e.g., via JIRA tickets.
• Test pipelines: Offer direct access to real-time test results, help identify flaky tests, etc.
• Deployment management: This allows developers to take control of deployments, track which deployments their changes are in, and manage feature flag states.
• Tracking code health: Actionable steps to track and reduce tech debt and improve code health for the engineering teams.

This shifts the focus from passively observing service states to actively improving developer workflows. If the tools developers use daily aren’t at the heart of your IDP, then it’s time to rethink the design.

This article is co-authored by Adam Berry and was originally posted on The New Stack.