Developer Experience (DevEx) has emerged as a critical factor in software development success. But what exactly is DevEx, and why should organizations care about it?
Developer Experience encompasses every interaction a developer has with tools, processes, and systems while building software. It includes:
Poor DevEx directly impacts productivity:
Happy developers are more productive and stay longer:
Better DevEx translates to business value:
It’s tempting to treat DevEx as a synonym for “building a developer portal.” It isn’t. When I say developer portal, I mean a concrete tool — usually a Backstage instance. When I say Developer Experience, I mean the whole ecosystem of processes around how developers find information, make decisions, and get work done. The portal is one instrument inside that ecosystem, not the goal itself.
This distinction matters, because the hardest and most valuable DevEx work often has little to do with shipping portal features. Structuring documentation, helping subject-matter experts write down what currently only lives in their heads, and turning informal, undocumented routines into processes people can actually rely on — that work frequently improves Developer Experience more than any new portal page.
It also reframes what Backstage is. Backstage is a framework, not a finished product. It gives you a canvas for encoding your organization’s processes as code, but someone still has to figure out what to encode. Every company is different — your pipelines, your ownership models, your documentation culture — so most of the early effort is discovery work, not development work.
A developer portal is easy to picture as a service catalog with some docs bolted on. That undersells it. At its core, a portal is a communication platform — closer to an internal news portal for your engineers than to a static wiki.
Think about what a news portal does: it doesn’t only inform, it shapes mood and attention. The same is true here. A portal decides what developers see first, which questions have obvious answers, and how easily they can reach the person who actually knows. Centralize that communication well — one source of truth, clear ownership, a path to the right human — and you remove a large amount of daily friction and uncertainty. Centralize it poorly, or not at all, and you’ve built a tool nobody opens. The technology is the smaller half of the work; the communication design is the larger one.
Track these metrics to understand your DevEx:
One warning from the field: be careful which numbers you celebrate. “Percentage of services catalogued” is easy to measure and easy to grow, but on its own it only tells you how much cataloguing work happened — not whether anyone’s experience improved. Treat catalogue coverage as table stakes, then measure the things that actually move the needle: cognitive load, how quickly a developer can find an answer or an owner, and satisfaction gathered in many small places rather than one annual survey. Measure broadly and often — a single headline number is usually a vanity metric in disguise.
Developer portals like Backstage provide:
DevEx is evolving with new technologies:
Organizations that invest in Developer Experience will see:
Developer Experience isn’t just about making developers happy—it’s about building a sustainable, productive development organization that can adapt and thrive in an increasingly complex software landscape.
Join the DevStage Bulletin to get updates on new Backstage plugins, exclusive Developer Experience insights and best practices in building developer portals.
Discover why successful organizational change requires empowering teams rather than imposing solutions through the lens ...
As software development accelerates and becomes more complex, traditional approaches to knowledge transfer and onboardin...
Kickstart your Backstage implementation with these practical steps to quickly prove value, build momentum, and secure su...