 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
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.
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.
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.
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:
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 part of The New Stack’s contributor network. Have insights on the latest challenges and innovations affecting developers? We’d love to hear from you. Become a contributor and share your expertise by filling out this form or emailing Matt Burns at mattburns@thenewstack.io.
