Developer Home

The Problem

When I started this project, Adobe had over 30 different interfaces that developers needed to navigate just to accomplish basic self-serve tasks. New engineers spent their first weeks figuring out what tools even existed. Senior engineers wasted hours shepherding them through it. Onboarding was measured in weeks, discoverability was tribal knowledge, and no one had a clear picture of who owned what.

The first question I had to answer wasn’t how to build a developer portal — it was whether to build one at all. We ran a genuine build-vs-buy evaluation, assessed the open-source landscape, and ultimately landed on Spotify’s Backstage. It had an active community, a plugin model that matched how we’d need to extend it, and enough foundation that we could focus on what was unique to Adobe rather than rebuilding the basics. The bet paid off, but it came with its own complexity.

Two Personas, One Portal

The hardest product design challenge wasn’t the technology — it was figuring out who we were actually building for. We had two very different users with very different needs.

Developers wanted easy ways to create and manage production-worthy software without having to hold a mental map of thirty internal tools. Platform teams wanted a way to connect with developers in an interface developers already trusted — one they didn’t have to teach people to use.

Developer Home became the connective tissue between these two archetypes. Everything we built was evaluated against both personas: does this help developers get unblocked, and does this give platform teams a coherent channel to reach them?

The Catalog

Catalog was where we started and where we invested the most. Most Backstage implementations rely on the out-of-the-box entity types — services, APIs, components. Adobe’s platform landscape was different. Different lines of business had built out shared platforms across the company: Kubernetes, API gateway, event bus, observability, CI/CD, releases, code scaffolding. Each platform had its own interface, its own terminology, and its own onboarding.

What we realized was that all of these platforms were connected, but developers couldn’t see those connections. We were asking engineers to do the manual integration work themselves — copying values between internal portals, cross-referencing documentation from different teams, piecing together a picture of how their service related to everything around it. We defined a set of core developer objects that cut across all of these platforms: clusters, microservices, APIs, event bus topics, namespaces, permissions groups, infrastructure, cloud accounts, networks and subnets. Then we built the relationships between them into the catalog and surfaced everything as a relational service map.

The scale we reached was something I was genuinely proud of — over 400,000 unique entities across all types, which was likely one of the largest Backstage catalog implementations anywhere. That scale came with real engineering challenges. The native Backstage backend is API-driven and was not designed for that volume. Load times became a serious problem. We ended up rearchitecting around an event-driven model to keep everything real-time and offload the pressure from the polling-based approach Backstage ships with. It was a significant lift, but it meant the catalog stayed current and felt fast.

Templates

The second major unlock was the template experience. There was no easy way for engineers to spin up a new service or create assets quickly. Every team had their own approach, and the platform ecosystem only supported a handful of languages, versions, and dependency configurations — but there was no clear way to understand what was available, let alone request it.

Backstage’s scaffolder gave us a solid foundation. The wizard-like experience let developers walk through a step-by-step flow to provision new microservices that came pre-wired with artifact management, security scanning, CI and CD tooling, observability, and network connectivity — all in one. The templating extensions and custom field types in the scaffolder turned out to be particularly valuable for inner-sourcing: teams would build templates with fields that required integrations into key systems, and those field components would get reused across other templates. The reuse compounded quickly.

We also gave the template playground its own attention. It became a space where teams could expose more experimental projects and share work that wasn’t quite ready for the official catalog. It was one of those features I didn’t expect to land the way it did — it sparked a lot of creativity and made inner-source contribution feel lower stakes.

Documentation

For docs, we had an interesting situation. Adobe already had an established internal documentation platform called Parliament — Markdown-based, widely adopted, and built by our own platform team. It had been used for years and had real traction. But it was built on a framework that was aging out of support, the onboarding experience had calcified, and it had gone largely uninvested for some time.

We made the call to centralize documentation inside Developer Home. This wasn’t just a migration — it was a chance to do it better. We improved the onboarding experience, rebuilt the search capability, and added richer features that Parliament couldn’t support. The one that got the most attention was the “Try it now” experience embedded directly in Swagger docs, which let developers test API calls without leaving the page. We also restructured the docs hierarchy from the old flat model into something with real depth and navigational structure. Teams that had lived with the limitations for years noticed immediately.

Dashboard

Dashboard was the last major feature I worked on before leaving Adobe, and honestly the one I was most excited about — because this was where Backstage had the most obvious gap.

I had been following Port’s approach to the developer portal dashboard closely. Their model was deeply extensible and tightly integrated with the rest of the portal ecosystem. I wanted something similar: a surface where teams could build panels showing custom information from catalog entities, embed step-by-step guides using templates, and pull in live data from developer systems like Jira, GitHub, and our CI/CD platform.

We built it using an existing React-Spectrum library internally, which made the authoring experience essentially no-code — teams could configure their dashboards without writing custom frontend code. Everything was wired to existing tooling, which meant contributions compounded rather than starting from scratch. I finished writing the requirements for this feature just before I left. I’m proud of the foundation we laid, even if I didn’t get to see it ship.

What I’d Do Differently

It wasn’t all forward momentum. There were real mistakes I’d approach differently in hindsight.

Push harder on adoption strategy from day one. Within a week of our proof of concept launching, VP-level questions started coming in: “How many people are using this?” The pressure to show numbers early pushed us toward a “lift and shift” approach — redirecting users from existing portals into Developer Home and surfacing those experiences as bespoke global plugins. These plugins were largely disconnected from the catalog, templates, and core Backstage features. The result was a portal that had six other portals inside it, each with its own design language and navigation patterns. Developers were confused and frustrated, and we spent months trying to convince people the mess was temporary. We eventually redesigned the product and rebuilt it with our inner-source contributors in a more coherent Adobe-native experience. But the early reputation was hard to shake.

Invest in the platform team persona earlier. A lot of the disconnected early experience stemmed from the same root cause: we hadn’t built the tooling, guardrails, documentation, design systems, or shared language that platform teams needed to contribute coherently. We had neglected the other side of the marketplace. If we had invested in the contributor experience earlier — the inner-source tooling, the plugin design patterns, the governance model — both personas would have gotten a better product sooner. The value for contributors would have been more obvious, and developers would have had a more cohesive experience as a result.

Take AI more seriously. This one stings a bit in retrospect. The developer portal’s implicit assumption for years has been “two tabs: GitHub and the developer portal.” That framing is becoming obsolete. Developers increasingly want to stay in their IDE or local environment, and AI is accelerating that shift faster than any of us anticipated. I remember evaluating opportunities to embed AI into Developer Home in early 2025 — but they felt additive, not transformative. Bolted on. What I understand now is that the right answer wasn’t to add AI features to a portal — it was to rethink the portal itself as a headless system that agents can query and act through. If I were starting this project today, I’d be building something fundamentally different: deeply agentic, interface-optional, and designed to serve IDEs and AI systems as first-class consumers alongside humans.