Beyond the portal hype: Why you need a platform first

When Spotify released Backstage as an open source project in 2020, it sparked a wave of enthusiasm across the platform engineering community. The promise was compelling: a unified dashboard where developers could discover, access, and consume everything they needed to build software efficiently. Who wouldn't want a sleek “shop front” to simplify the increasingly complex world of software development?

Fast forward to today, and the reality has proven more complicated. Despite the initial excitement, many organizations struggle to realize the promised benefits of internal developer portals.

Portals vs. platforms: What’s the difference?

An internal developer portal is a “front door” to your technical ecosystem. It sits atop your developer platform, which integrates different tools to provide standardized workflows and underlying infrastructure and helps enforce governance. While the platform handles the technical implementation of tooling and automation, the portal provides a single pane of glass that makes development resources discoverable and accessible.

Before we get to the challenges around portals, it’s worth acknowledging the very real challenges they aim to address:

1. Discovery obstacles: Many organizations lack an API catalog, causing developers to struggle to find existing software components, documentation, best practices, and support channels. Portals attempt to solve this by creating a centralized catalog where developers can access these resources through a unified search and navigation experience.
2. Tool sprawl: The modern software development lifecycle relies on numerous specialized tools, each with its own interface and learning curve. GitLab research found that 62% of teams use six or more separate tools for software development. Portals address this by integrating these disparate tools behind a consistent interface, reducing the cognitive load of context switching.
3. Siloed knowledge: Teams focused on their specific challenges often create their own workflows and toolchains, hampering cross-team collaboration and leading to duplicated work. Portals aim to break down these silos by making team assets visible across the organization and promoting standardized workflows that encourage collaboration and reuse of existing solutions. These challenges have a measurable business impact: According to the 2024 GitLab Global DevSecOps Report, 78% of developers spend at least a quarter of their time maintaining and integrating toolchains.

Why portal initiatives often fall short

If internal developer portals address genuine business problems, why do these initiatives regularly fail to gain traction? In my conversations with technical leaders at companies of all sizes, I’ve noticed several key factors:

1. Insufficient product management: Many organizations underinvest in release announcements, internal enablement examples, training, and other adoption-fueling activities essential for portal success.
2. Dependency on platform capabilities: A portal is only as valuable as its underlying platform. Without robust platform capabilities, a portal merely presents a unified view of dysfunction.
3. Technical complexity: Organizations often underestimate that a portal is not simply a tool to install but a software development framework requiring significant engineering skills to build and maintain.
4. Ongoing investment requirements: Building and maintaining a portal demands substantial continuous investment, which many organizations underestimate during initial planning stages.
5. Limited developer resonance: Despite being highly discussed in platform engineering circles, a recent CNCF App Development Working Group survey revealed that many developers remain unaware of Backstage — suggesting it may not address problems developers consider material to their work.

These challenges are particularly acute when building the portal’s frontend interface. A portal essentially functions as a wrapper built around existing tools, aiming to become the single source of truth for developer interactions.

But here's the catch: If your portal doesn't mirror enough of the functionality of those underlying tools, developers will bypass it and go straight to the underlying tools, making your portal just another item in an already crowded toolchain. At the same time, trying to keep up with feature changes across a dozen backend tools requires a massive ongoing effort. Every time a backend system changes or releases a new capability, the portal team faces the same question: implement, integrate, or ignore? Providing a single pane of glass is a significant, perpetual engineering investment that most organizations underestimate.

Netflix, which has deep experience in developer tooling, puts it bluntly: “A common front door for existing tools is insufficient on its own to attract and keep a user base. Rather [it] needs end-to-end experiences not available in other tools to keep users coming back and discovering the additional features and capabilities.”

The platform-first approach

Organizations that have successfully improved developer productivity typically follow a platform-first approach rather than beginning with a portal. Here’s what this looks like in practice:

1. Start with developer needs: Don’t assume what developers need. Speak directly with teams about their challenges and work closely with them to develop solutions that demonstrably improve their day-to-day experiences.
2. Focus on platform capabilities first: Prioritize creating streamlined, automated workflows for regular tasks that incorporate best practices and corporate standards. Any future portal's value will entirely depend on these underlying capabilities.
3. Consider tool consolidation before integration: Portals primarily solve integration issues between tools by abstracting authentication methods and bringing data sources together. Before investing in complex integrations, evaluate whether consolidating tools might simplify your ecosystem. End-to-end solutions across the software development lifecycle can reduce the need for extensive integration work.
4. Invest in product management: Ensure strong product management to encourage platform adoption by new teams and drive new capability adoption by teams who have already embraced the platform.

When portals make sense

This isn’t to say that internal developer portals are inherently flawed. In fact, I’ve worked with several large, mature organizations that successfully use internal developer portals like Backstage, but with a crucial difference in approach and expectations.

One large financial institution I worked with recently has had tremendous feedback from their portal implementation. Rather than trying to create a single pane of glass for all development activities, their portal was built to serve two specific workflows: developer onboarding and new project scaffolding. When a developer joins a team, the portal guides them through account setup across six different systems, automatically provisioning access based on their team assignment. For new projects, the portal provides developers with an intuitive interface to select an appropriate template and configure it to their needs. The portal then triggers the necessary backend systems to build the required project scaffolding, including an initial code repository and a CI/CD pipeline with policy-driven testing and infrastructure-as-code to deploy the application.

Successful implementations like this leverage portals for activities that genuinely benefit from a simplified point-and-click interface. The portal doesn't try to be the primary interface for all activity; developers still work directly in their IDEs, Git repositories, and monitoring dashboards. Critically, organizations with successful developer portals build solid, capable internal developer platforms first. They also have mature approaches to gathering developer feedback to direct their efforts to real-world points of friction.

The path forward

The message for technical leaders navigating the platform engineering landscape is clear: Start with a strong platform rather than focusing primarily on a portal. Prioritize creating tangible value for developers through automation, standardization, and simplified workflows. Once your platform capabilities mature and deliver measurable benefits, consider adding a portal as an enhancement if specific needs warrant it.

By taking this measured approach, you'll avoid the common pitfall of implementing a beautiful dashboard that sits atop dysfunction — and instead build developer tooling that genuinely improves productivity, reduces cognitive load, and accelerates innovation.