Glossary
A developer experience platform removes friction from the engineering workflow by providing tools, insights, and automation that multiply team effectiveness.
When I joined Salesken as CTO, our build times were 18 minutes. Fixing developer experience became my highest-leverage investment.
A developer experience (DX) platform is infrastructure or tooling designed to make developers more productive and happy. It encompasses documentation, APIs, SDKs, testing frameworks, deployment tools, and support. Good DX platforms reduce friction and enable developers to build faster.
Developer experience platforms include:
Adoption: Good DX increases adoption. Developers choose tools that are easy to use.
Productivity: Good DX makes developers faster. Less friction = more feature work.
Retention: Developers stay with products that respect their time and experience.
Community: Good DX attracts community contributions and word-of-mouth.
Business Impact: Better DX correlates with higher retention and lower churn.
"DX is just documentation." False. Documentation is part of DX but not all. APIs, tooling, and support matter too.
"Good DX is expensive." False. Often cheaper than poor DX (support burden, low adoption).
"We can improve DX later." False. DX built in from start is better than retrofitted.
API Design: Part of DX.
Developer Onboarding: Part of DX.
Codebase Documentation: Part of DX for internal developers.
An Internal Developer Platform is infrastructure built by a platform team to serve other developers in the organization. Unlike external developer platforms (like Stripe's API or Twilio's SDK), IDPs focus on internal productivity.
Key components of a mature IDP:
Self-Service Infrastructure Developers can provision environments, databases, and services without filing tickets. Instead of waiting days for a staging environment, they click a button and get one in minutes.
Golden Paths Pre-configured templates and workflows for common tasks. Want to create a new microservice? The platform provides a template with CI/CD, monitoring, logging, and deployment already configured. This reduces setup time from days to minutes.
Service Catalog A searchable directory of all services, their owners, dependencies, and health status. Tools like Backstage, Cortex, and OpsLevel provide this. When something breaks at 2 AM, the on-call engineer can find the owner in seconds.
Developer Portal A single entry point where developers find documentation, tools, services, and support. Instead of searching Confluence, Slack, and GitHub, everything is in one place.
The platform team builds and maintains the IDP. They treat other developers as customers. Their success metric is developer productivity and satisfaction, not features shipped.
Team size guidelines:
| Metric | What It Measures | Good Benchmark |
|---|---|---|
| Time to first commit | How long until a new hire pushes code | < 1 day |
| Time to provision environment | Self-service infrastructure speed | < 15 minutes |
| CI/CD pipeline duration | Build and deploy speed | < 15 minutes |
| PR review turnaround | Code review responsiveness | < 4 hours |
| Deployment frequency | How often teams ship | Multiple times/day |
| Developer satisfaction (NPS) | Overall experience | > 40 |
| Tool | Category | Best For |
|---|---|---|
| Backstage (Spotify) | Developer portal | Large organizations with many services |
| Cortex | Service catalog | Platform teams tracking service maturity |
| OpsLevel | Service catalog | Teams needing ownership and standards tracking |
| Port | Internal developer portal | Teams wanting no-code portal building |
| Humanitec | Platform orchestrator | Teams automating environment provisioning |
| Tool | Category | Best For |
|---|---|---|
| Glue | Codebase intelligence | PMs and leaders understanding code |
| Sourcegraph | Code search | Developers searching across repos |
| CodeSee (GitKraken) | Code visualization | Developers visualizing dependencies |
| Swimm | Code documentation | Engineers documenting flows |
| Tool | Category | Best For |
|---|---|---|
| Glue | Engineering metrics | DORA metrics tracking |
| Swarmia | Team productivity | Workflow optimization |
| DX (GetDX) | Developer surveys | Measuring developer experience |
| Glue | Engineering management | Aligning engineering to business |
in my experience, strong correlation between developer experience and business outcomes:
For CTOs and engineering leaders, investing in developer experience is not a cost center — it is a direct driver of feature velocity, engineer retention, and product competitiveness.
Traditional DX platforms focus on infrastructure (environments, CI/CD, monitoring). But developers also spend significant time trying to understand code they didn't write. This is where codebase intelligence fills a gap:
This is the "understanding" layer of developer experience — complementary to the "infrastructure" layer that traditional DX platforms provide.
Q: How do you measure DX? A: Developer satisfaction surveys, adoption rates, support tickets, community activity.
Q: What's the biggest DX problem? A: Usually poor documentation or unclear APIs. Fix those first.
Q: Should internal and external DX be the same? A: Similar principles but tailored to audience. Internal DX focuses on speed. External DX focuses on ease of learning.
Keep reading
Related resources
