Your Backstage Capability Page Is Where Developer Experience Lives or Dies

Backstage is where developers actually look.

Not the wiki. Not the Slack pin. Not the email the platform team sent in March announcing the new API. Backstage. Because Backstage is the place developers go when they have a real question — what already exists, who owns it, is it healthy, can I use it.

If your capabilities are not in the Backstage catalog, they do not exist — not in any way that translates into adoption. The most beautifully-spec’d capability in your repo is invisible if a developer cannot find it from the page they already have open.

Developer experience is not a documentation problem. It is a catalog problem. And the catalog page is where the developer experience either lives or dies.

What Naftiko Fleet ships in Backstage today

The Naftiko Fleet plugin treats the Backstage capability page as the primary surface where a developer encounters a capability. Not as one of many surfaces. The primary one.

What ships today:

• NaftikoCapabilityEntityProvider — auto-catalog from NaftikoCapability Custom Resource Definitions or directly from Git repos. New capability merged to main? It is in the catalog within minutes. No manual registration.
• NaftikoCapabilityCard — the card that renders on the capability page, showing topology (consumes graph + exposes graph), lifecycle status, ownership, and stakeholder information at a glance. The developer sees what calls what without reading YAML.
• Catalog enrichment of API entries — when a capability exposes a REST API, the existing Backstage API catalog entry is enriched with capability metadata. The capability and the API stay linked instead of drifting apart.
• Capability-search and reuse-pattern detection — find capabilities that wrap the same upstream APIs, surface duplication, drive consolidation. Standard Edition.
• MCP server integration — the Backstage MCP server lets AI agents query the capability catalog directly. The catalog itself becomes an agent-callable surface.

That last one is the thing most platform teams do not realize they want until they have it. Once Copilot can query “what capability already exists that talks to Jira?” from inside the IDE, the developer-experience picture changes shape.

Where the Backstage integration is going

The Naftiko Fleet roadmap brings three additions over the next two milestones, each one closing a specific developer-experience gap:

• TechDocs integration (Second Alpha — End of April 2026) — every capability scaffolded from a Naftiko Backstage template gets TechDocs enabled by default. Capability documentation lives next to the capability itself in the catalog, rendered through Backstage’s standard TechDocs pipeline. The wiki page for a capability is not a separate Confluence document — it is the same artifact that ships with the runtime.
• Backstage Kubernetes plugin (Third Alpha — End of May 2026) — developer-centric monitoring for the capability page. When a developer is debugging a capability they own, the metrics for that capability are one click from where they live. The /metrics endpoint the Naftiko Framework already exposes feeds the Kubernetes plugin without any extra wiring. Free feature candidate in Community Edition.
• Tech Radar plugin focused on capabilities (Third Alpha) — Backstage’s Tech Radar visualization, but instead of cataloging technologies, it catalogs the capabilities your fleet runs and where each sits on the adopt → trial → assess → hold curve. New capability shipped? It enters at “trial.” Capability in steady state for six months with broad reuse? “Adopt.” Capability nobody has called in a quarter? “Hold.” The Radar is the executive view of the capability fleet — the same view a Head of Platform or VP of Engineering wants in front of them.

The Naftiko Templates for Backstage page

The Naftiko Fleet wiki documents the scaffolding pattern in the Naftiko Templates for Backstage page. The templates are how developers create new capabilities — not by hand-writing YAML from scratch, but by selecting a template, filling in three fields, and getting a capability that ships with all the runtime defaults already in place.

The Second Alpha is adding the ability to scaffold a capability from existing APIs with proper lineage. Drop in your OpenAPI spec, point at the upstream, get a working capability YAML with consumes wired up, exposes generated, and governance tags pre-populated from the org’s defaults. The capability is in the Backstage catalog before the developer finishes reading the README.

This is the difference between Backstage as documentation hosting and Backstage as a capability-creation surface. The Naftiko Fleet templates push it to the second.

Three dimensions of catalog DevX

Technology: the catalog page is the entry point. Topology graph, live metrics, owner, stakeholders, scaffolding template, TechDocs, Tech Radar position — all on one page, all auto-populated from the capability YAML, all linked back to the runtime artifact. There is no separate developer portal to maintain.

Business: the time-to-discovery for “does this already exist?” drops from a Slack message to zero seconds. Reuse becomes the first thing a developer encounters, not the last. Duplication drops because the existing capability is visible before the duplicate gets started.

Politics: the capability page is where the platform team’s investment in standards becomes legible to the rest of the engineering organization. The Tech Radar visualization is the artifact your VP of Engineering will reference in their next all-hands. The capability card is the page your auditors will reference in their next compliance review. The catalog earns its keep because it is where the cross-functional conversations actually happen.

What to do with this

If your enterprise has Backstage but your capabilities live somewhere else — a wiki, a portal, a folder of Markdown — the developer-experience layer is broken. Not failing in some abstract sense. Failing in the specific, daily-reuse sense that compounds across every developer who cannot find what already exists.

The Naftiko Fleet plugin moves capabilities to where developers already look. The roadmap closes the remaining gaps over the next two milestones. The wiki documents the patterns.

Your Backstage capability page is where developer experience lives or dies. Naftiko Fleet is the runtime that keeps it alive.