Internal Developer Platforms — Building IDPs Developers Actually Use

Why this matters now

Most companies with 50+ developers face the same problem: fragmented internal tooling. CI/CD in one place, observability in another, documentation scattered across Notion, infrastructure provisioning via tickets to the SRE team. The result is time lost to context switching and human dependency for tasks that should be self-service.

In 2026, the Internal Developer Platform (IDP) concept has matured from buzzword to engineering standard — driven by the Backstage ecosystem, which reached production stability and significant adoption among hyperscalers and tech companies.

What an IDP is (and isn't)

An IDP is an abstraction layer that gives developers the infrastructure capabilities they need without requiring detailed operational knowledge.

It is:

• A unified interface to create, manage, and operate services
• Golden paths that encapsulate organizational best practices
• Self-service for common operational tasks (provision environments, create services, configure monitoring)
• A service catalog with metadata, ownership, and dependencies

It isn't:

• Another portal nobody uses
• A project that can be delegated exclusively to the platform team without input from users
• A solution that replaces culture and process with tooling

The Backstage ecosystem in 2026

Backstage, created by Spotify and now a CNCF graduated project, is the de facto standard for IDP implementation. Its plugin-based architecture enables progressive composition:

• Service Catalog: centralized inventory of services, APIs, teams, and resources
• Software Templates: golden paths to create new services with pre-configured CI/CD, observability, and documentation
• TechDocs: tech docs-style documentation, versioned alongside code
• Search: unified search across all cataloged components

Essential plugins in 2026:

• backstage-plugin-kubernetes: workload visibility
• backstage-plugin-argocd: deploy status and rollback
• backstage-plugin-graphiql: GraphQL API exploration
• backstage-plugin-cost-insights: cost visibility per service
• backstage-plugin-techdocs: integrated documentation

Software Template example

yaml# templates/new-service/template.yaml
apiVersion: scaffolder/v1beta3
kind: Template
metadata:
  name: new-microservice
  title: Create New Microservice
spec:
  owner: platform-team
  type: service
  parameters:
    - title: Service Info
      required:
        - name
        - owner
      properties:
        name:
          title: Service Name
          type: string
        owner:
          title: Owner Team
          type: string
          ui:field: EntityPicker
          catalogFilter:
            kind: Group
  steps:
    - id: fetch
      name: Fetch Template
      action: fetch:template
      input:
        url: ./skeleton
        values:
          name: ${{ parameters.name }}
          owner: ${{ parameters.owner }}
    - id: publish
      name: Publish to Catalog
      action: catalog:register
      input:
        catalogInfoUrl: ${{ steps.fetch.output.entityUrl }}
    - id: create-argocd
      name: Create ArgoCD Application
      action: argocd:create-application

Practical framework for building an IDP

Phase 1 — Discovery (2-4 weeks)

Don't start with Backstage. Start with the problem.

1. Map friction points: interview developers about tasks that take more time than they should
2. Identify the "top 5": prioritize the 5 most frequent and painful tasks
3. Define baseline metrics: time to create a new service, time to provision an environment, escalation frequency to the platform team

Phase 2 — MVP (4-8 weeks)

Implement golden paths for the top 5, not a complete platform.

1. Service Catalog: inventory existing services with ownership and dependencies
2. 1-2 Software Templates: for the most common patterns (e.g., Go microservice with ArgoCD)
3. Integration with 1-2 systems: likely Kubernetes + existing CI/CD

Phase 3 — Evolution (ongoing)

Expand based on adoption, not on the platform team's wishes.

1. Add observability: logs, metrics, and traces visible per service
2. Add documentation: TechDocs integrated into the service lifecycle
3. Add cost: cost visibility per service and per team

Measuring success — DORA and beyond

Metrics that matter:

Common pitfalls

1. Building for everyone at once: start with 1-2 pilot teams. An IDP nobody uses is a failed IDP.
2. Focusing on technology, not the problem: if developers don't complain about the current tool, maybe they don't need an IDP yet.
3. Replacing culture with tooling: IDP accelerates existing best practices, it doesn't create best practices that don't exist.
4. Ignoring legacy tool migration: if the company has 200 services and ad-hoc creation scripts, migration is the real project — not the new platform.
5. Not measuring: without before and after metrics, it's impossible to justify the investment.

Next steps

1. Run the discovery exercise: 5 interviews with developers and 3 with SREs already give a clear picture
2. Identify the first golden path: probably "create a new microservice with everything set up"
3. Install Backstage locally: run npx @backstage/create-app@latest and explore existing templates
4. Define success metrics before implementing: without a baseline, there's no improvement — just opinion

Need to build or evolve an Internal Developer Platform? Talk to Imperialis about platform engineering and create golden paths that teams actually adopt.