What a developer portal actually does, in plain terms

The problem it solves

Picture a developer joining a team with 200 services in production. They need to ship a small change to one of them. Before they can write a line of code, they need to answer a few basic questions: who owns this service, what does it depend on, what’s the process for deploying it, and is there a standard this service is supposed to meet that it currently doesn’t.

Without a portal, those answers live in different places. Ownership might be in a spreadsheet that’s six months out of date. Dependencies might only be knowable by reading the code or asking around on Slack. The deployment process might be documented in a wiki page nobody’s updated since the last person who owned it left the team. Compliance status might not be tracked anywhere at all until something breaks.

A developer portal exists to put all of that in one place, kept current, so the answer to “who owns this and what do I need to know” doesn’t depend on finding the right person to ask.

The core components

The core piece is a service catalog: a list of every service, with its owner, its dependencies, and whatever metadata the organization cares about.

On top of that, most portals add a way to track standards, often called scorecards, so a team can see at a glance whether a service has monitoring set up, passes its security scans, or meets whatever bar the organization has set for production readiness.

Many portals also add self-service tools, so a developer can spin up a new service, request infrastructure, or trigger a deployment pipeline without filing a ticket and waiting on another team.

Why this is harder than it sounds

None of this is complicated in concept. What makes it hard in practice is keeping it accurate as the organization grows. A catalog that’s manually maintained falls out of date within weeks, because services get created, deprecated, and reassigned constantly, and nobody has the time to update a spreadsheet every time that happens.

This is why most modern portals emphasize automatic discovery, pulling ownership and dependency information directly from the tools teams already use (source control, CI/CD, incident management) rather than relying on someone to type it in.

The organizational payoff is straightforward: less time spent hunting for information, fewer inconsistent processes across teams, and fewer blind spots where a service quietly falls out of compliance because nobody was watching. None of that is new. It’s the same reason developer portals became a standard part of engineering infrastructure well before AI entered the picture.

What has changed is who’s reading this information, and what they’re capable of doing with it.

Who a developer portal is actually for

The name suggests this is a developer tool, and developers are the primary users. But the portal ends up serving several roles at once, because ownership, standards, and service health are things more than one function cares about.

Platform engineers

Build and maintain the portal itself. They decide what goes in the catalog, what standards get tracked as scorecards, and what self-service actions are safe to expose. Their success is usually measured in adoption: whether developers actually use the portal instead of working around it.

Developers

Use the portal to find what they need without asking someone else first: who owns a service, what its dependencies are, whether it’s safe to touch. Self-service actions let them scaffold a service or request infrastructure directly, instead of filing a ticket and waiting on another team.

Engineering managers

Use scorecards and dashboards to see compliance and performance across their team without having to ask for a status update. This is also where a portal starts connecting engineering conditions to outcomes leadership cares about, since a manager can point to specific standards gaps rather than a general sense that “things feel slow.”

Security and compliance teams

Use the portal to see, at a glance, which services meet a given standard and which don’t, instead of running a manual audit every quarter. Scorecards make this an ongoing check rather than a periodic scramble.

SREs

Use the software catalog to understand ownership and dependencies quickly during an incident, which matters most exactly when time matters most. This is also where a portal overlaps with broader site reliability engineering practice.

The pattern across all of these roles is the same: the portal replaces “ask around and hope someone knows” with “look it up.” That’s a small thing on any single occasion and a significant one at the scale of hundreds of services and a growing team.

What tends to go wrong without one

Without a shared source of truth, several problems tend to show up together, and they compound rather than staying isolated.

Lost time to context switching

Developers lose real working time finding the right owner, waiting on another team for something they could do themselves, or piecing together dependency information from source code because nothing else is current. This is the same friction DX’s research on developer conditions consistently surfaces: the more a developer has to context-switch to get basic information, the less time they spend in a productive state, and the effect compounds across a team.

Standards drift

Without a consistent way to track compliance, security, and production readiness across every service, some services quietly fall behind and nobody notices until something breaks. This isn’t a failure of individual engineers; it’s what happens by default when there’s no ongoing mechanism to catch it.

Slower onboarding

A new engineer without a central place to find ownership, standards, and process ends up learning through trial and error, or by interrupting people who already have their own work to do.

None of this shows up as one dramatic failure. It shows up as a slow accumulation of friction that’s easy to normalize because no single instance of it looks like a crisis.

Why AI changes what a portal needs to do

AI coding agents don’t use a portal the way a developer does. A developer opens a browser, searches, and reads. An agent needs the same information delivered as structured, queryable data it can act on directly.

This distinction matters because AI agents amplify the conditions already present in an engineering organization. Teams with clear ownership, current documentation, and reliable CI/CD tend to see real gains from AI-assisted development. Teams without that foundation see the opposite: agents generating code that doesn’t account for existing architecture, missing dependencies, and rework that offsets any speed gained. The agent isn’t what determines the outcome. The quality of the context it has access to is.

A portal built primarily as a UI for humans doesn’t automatically solve this. The data can be accurate and still be inaccessible to an agent if it was never modeled or exposed in a way agents can query.

Three layers worth separating

What DX Fabric provides

DX builds engineering intelligence software used by teams at companies like Adyen, Dropbox, Vanguard, and Booking.com. Fabric is the part of that platform built to be the context layer described above, the systems catalog, scorecards, and self-service data that both a portal and an AI agent can draw from.

The clearest way to see how this fits together is through DX’s relationship to Backstage specifically. Backstage gives platform teams a flexible interface, but building and maintaining the catalog underneath it is its own project: pulling data in from dozens of tools, keeping it current, and turning it into something teams actually trust. DX plugs into Backstage as an entity provider, handling catalog management directly rather than leaving each team to build that plumbing on its own. It also functions as a missing data lake for Backstage, ingesting data from over 40 development tools and joining it with existing entities to enrich the catalog with metadata that would otherwise take significant engineering time to assemble by hand. On top of that data, SQL-powered scorecards embed directly into Backstage with task lists teams can act on, and metrics built from that same data lake show up as pre-built components inside the Backstage UI.

One platform team put it plainly: they said they didn’t know how they’d operate without the data DX provides. That’s the role Fabric plays, not a competing portal, but the data foundation that makes a portal like Backstage, and the agents increasingly working alongside it, actually reliable.

The five pieces below build on each other rather than functioning as separate products: catalog data feeds the scorecards, scorecards feed self-service and agent actions, and guardrails wrap around all of it.

Systems catalog

A live record of ownership, dependencies, and metadata for every service, kept current through automated discovery rather than manual entry. This is the foundation everything else in Fabric builds on, since scorecards and agent context are only as good as the catalog underneath them.

Context management

The layer that turns catalog and scorecard data into something an agent can use directly, exposed through DX MCP so agents across different tools can query the same information rather than each maintaining their own partial view. This also includes guardrails on what agents are permitted to act on, since giving an agent access to context is a separate decision from giving it permission to make changes, and Fabric treats those as two distinct settings, not one.

Scorecards

SQL-powered tracking of engineering standards: production readiness, security compliance, migration progress. Teams define the rules directly in SQL rather than working within a fixed schema, which matters because standards tend to change as often as the stack does.

Self-service workflows

Common requests, service scaffolding, pipeline setup, resource provisioning, handled through governed, self-serve actions rather than tickets, with the same permission model applying whether the request comes from a person or an agent.

Agent ops tools and AI readiness

Direct visibility into whether the underlying conditions, ownership clarity, documentation, CI/CD reliability, are solid enough for agentic workflows to help rather than introduce risk. AI readiness is the honest check most teams skip in the rush to roll out agents, and it’s worth doing before the rest of this matters much.

Put together, this is what lets a scorecard failure become an assigned fix rather than just a flagged issue: when a service falls short of a defined standard, an agent with catalog access and the right guardrails can open a PR against it directly, with a person reviewing before it merges. That loop, standard defined, gap detected, agent proposes a fix, human approves, is the shape of what Fabric is actually for.

Using Fabric without an existing portal

Not every organization has Backstage or another portal UI in place yet. For those starting from nothing, Fabric works as a standalone layer, since it already includes catalog, scorecards, and self-service in one place. This is a reasonable starting point for organizations that want to close the AI context gap without taking on a separate portal build at the same time, and it can plug into a portal UI later without needing to redo the underlying catalog work.

Common questions

Is a developer portal the same as an internal developer platform?

No. The platform (IDP) is the set of tools developers use to build and ship: CI/CD, provisioning, infrastructure as code. The portal is the interface layer that gives developers access to those tools, plus ownership, standards, and self-service, in one place.

Is this the same as an API developer portal?

No, and the two get confused because they share a name. An API developer portal, the kind companies like Discord, Amazon, and Stripe run, is a public-facing docs hub for third-party developers building against an API. An internal developer portal is a private tool for an organization’s own engineers. This piece is about the internal kind.

Does a developer portal require Backstage?

No. Backstage is one way to build the portal UI, and a common one, but it’s a framework organizations build on rather than a finished product. Some organizations build on Backstage, some use a platform that provides the catalog, scorecards, and self-service layer without a separate build project, and some do both, keeping a portal UI while getting the underlying data layer from elsewhere.

What’s the difference between a developer portal and a context layer like Fabric?

A portal is built primarily as an interface for people. A context layer is built to be queried directly, by a portal UI, by an AI agent, or by both, which matters as more of the day-to-day consumption of this data shifts from developers reading a page to agents acting on structured data.

Choosing an approach

The build vs. buy question hasn’t gone away, but the stakes are different now, since a data layer other systems and agents depend on is more consequential to get wrong than a catalog only humans read. A few questions tend to clarify the decision:

Teams with an existing portal UI they like generally keep it and fix the data layer underneath. Teams starting fresh often get to a working state faster with a platform that provides catalog, scorecards, and self-service together.

Rolling it out

Adoption tends to fail when it starts too broad. A narrower start works better: one team, one service catalog populated through automatic discovery, one scorecard tied to a standard that already matters, like production readiness or a known security gap.

From there, expansion should follow evidence of use, not a fixed timeline. A scorecard that drives real fixes earns the next one. A self-service action that gets used earns the next workflow.

What to measure

The useful metrics are the ones that show whether the system is actually being used, not just installed.

• Catalog freshness: how much of the data is current versus stale
• Scorecard compliance trend over time, not a single snapshot
• Time to first commit for new engineers, since onboarding speed is one of the clearest signals a catalog is working
• Whether agent-generated changes are landing clean, which is the AI-era addition to this list

Governance and access

Agent guardrails matter, but human access control still comes first. Role-based access, single sign-on, and clear audit trails on who changed what standard should be in place before scorecards and self-service actions are exposed broadly. The same discipline that governs what a person can change in production should govern what an agent can change too, not a looser version of it.

Where this goes wrong

The most common failure isn’t a bad tool choice. It’s a catalog that gets built once and never maintained, which quietly becomes as unreliable as the spreadsheet it replaced. A close second is scorecards that get created and never tied to action, so gaps get visibility but no fix. A third is self-service tools built for problems developers weren’t actually stuck on, which sit unused while the real friction goes untouched.

All three are solvable, but only if adoption and upkeep get the same attention as the initial build.

Where to focus next

The condition worth checking first isn’t whether a portal exists. It’s whether the data underneath it, ownership, standards, dependencies, is current and complete enough for an agent to act on safely. That single check determines whether everything above actually pays off, or just adds a new layer of tooling on top of the same old gaps.