Developer Portal for a 200-Person Engineering Org
Led the creation of an internal developer portal that became the single source of truth for APIs, services, and runbooks across a 200-person engineering organization. Service discovery time dropped 70% and incident response improved 35%.
Challenge
Engineers across 12 teams had no central place for APIs, runbooks, or service ownership — leading to duplicated effort and slow incident response.
Solution
Internal developer portal with a service catalog, API documentation, runbook integration, and clear ownership mapping.
Result
Service discovery time reduced by 70%, incident response time improved by 35%, and the portal reached 92% weekly active usage within three months.
The Problem
At a large healthcare technology company, our engineering organization had grown to 200 developers across 12 teams managing over 60 microservices. The problem was not technical complexity — it was discoverability. Nobody knew what services existed, who owned them, or where to find their API docs. Runbooks were scattered across wikis, READMEs, and individual team Notion pages. During incidents, the first 10 minutes were often spent figuring out who to page and where to find the relevant runbook. I ran a developer experience survey and the results were clear: 78% of engineers said finding information about other teams' services was their biggest friction point.
What We Built
I led a cross-functional initiative to build an internal developer portal. The goal was simple: one place to find every service, its owner, its APIs, and its operational runbooks. We evaluated build-vs-buy options and chose to build on top of Backstage, customizing it heavily for our needs.
The portal had four core components. A service catalog where every microservice was registered with ownership, dependencies, SLAs, and health status. An API documentation hub that auto-generated docs from OpenAPI specs checked into each repo. A runbook library linked to services and integrated with our incident management tool. And a search layer that let engineers find anything by keyword, team, or domain.
The hardest part was not the technology — it was adoption. I worked with each of the 12 team leads to ensure their services were cataloged accurately. We built a CI check that flagged PRs creating new services without a portal entry. I also ran a "portal week" campaign where teams competed to have the most complete and up-to-date entries.
The Outcome
Within three months, the portal hit 92% weekly active usage — meaning nearly every engineer visited it at least once a week. Service discovery time dropped by 70% based on follow-up survey data. Incident response time improved by 35% because on-call engineers could immediately find the right runbook and the right owner. Duplicate API development — where two teams unknowingly built similar endpoints — dropped to near zero. The portal also became the foundation for our platform engineering roadmap, giving us a clear picture of service health, dependency graphs, and documentation coverage across the entire org.