{"id":4271,"date":"2025-05-14T15:04:17","date_gmt":"2025-05-14T15:04:17","guid":{"rendered":"https:\/\/www.aviator.co\/blog\/?p=4271"},"modified":"2025-09-23T13:02:05","modified_gmt":"2025-09-23T13:02:05","slug":"internal-developer-portals-internal-developer-hubs","status":"publish","type":"post","link":"https:\/\/www.aviator.co\/blog\/internal-developer-portals-internal-developer-hubs\/","title":{"rendered":"Internal Developer Portals Should Be Internal Developer Hubs"},"content":{"rendered":"
\"\"<\/figure>\n\n\n

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

If we strip away the marketing hype, many of these tools function more like portals \u2014 a window into service ownership and status \u2014 than actual developer platforms. It\u2019s time to rethink IDPs not as \u201cportals\u201d but as \u201chubs\u201d that actively route information and workflows, reducing developers\u2019 toil rather than creating another layer of friction.<\/strong><\/p>\n\n\n\n

IDPs are portals that display service information to developers, but that\u2019s 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.<\/p>\n\n\n\n

Why Portals Fall Short<\/h2>\n\n\n\n

By their nature, portals are passive. They allow developers to see what\u2019s happening but don\u2019t let them take meaningful action<\/strong>. If your IDP is just another place to look at dashboards, check service ownership, and perform administrative work, it\u2019s 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.<\/strong><\/p>\n\n\n\n

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\u2019t directly benefit from maintaining it. It\u2019s a two-sided network of sorts, but with an imbalance that leads to stale data, creating what we often call Zombie Tools \u2014 systems that exist but are underutilized or ignored by the very people they\u2019re meant to serve<\/strong><\/p>\n\n\n\n

Rather than considering IDPs as portals, we should conceptualize them as *hubs*. A hub is more than a window to view data \u2014 it\u2019s 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<\/strong> \u2014 whether that\u2019s triggering a deployment, performing a code review,<\/a> or tracking down the origin of a failing test.<\/p>\n\n\n\n

The IPP (Internal Platform Portal) Dilemma<\/h2>\n\n\n\n

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

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

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?<\/strong><\/p>\n\n\n\n

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.<\/p>\n\n\n\n

How To Turn IDPs Into Developer Hubs<\/h2>\n\n\n\n

The biggest flaw of today\u2019s 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 \u2014 reducing friction in their daily work.<\/p>\n\n\n\n

A \u201chub\u201d approach would mean integrating tools that developers care about:<\/p>\n\n\n\n