Platform Engineering: Building IDPs That Devs Actually Use

Platform engineering stopped being a buzzword the moment Gartner put it on its Hype Cycle and Spotify open-sourced Backstage. But between the slide deck and a working Internal Developer Platform (IDP) sits 12 to 18 months of opinionated decisions. Most platform teams we audit at DCT have shipped a service catalog, called it an IDP, and wondered why developer satisfaction didn't move. This post is about closing that gap.

What an IDP actually is (and isn't)

An IDP is not a Backstage instance. It's the sum of three layers:

1. Infrastructure primitives — Kubernetes, managed databases, secrets stores, observability stack.
2. Golden paths — opinionated, paved roads from git init to production: a Java service with Postgres, a Python ML pipeline, a Next.js front-end.
3. A developer interface — the portal (Backstage, Port, Cortex) plus a CLI, plus the IDE integrations.

If you only build layer 3, you've built a wiki with React. If you skip layer 2, every team reinvents the same Terraform module. The whole point of platform engineering, as described in Team Topologies, is to reduce cognitive load for stream-aligned teams. No golden paths, no reduction.

Golden paths, concretely

A golden path is a templated, supported, monitored way to do something common. Backstage's Software Templates (powered by scaffolder-backend) are the de-facto pattern. Here's a minimal template that bootstraps a Go service with CI, Helm chart, and SLO dashboard:

apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: go-microservice-v2
  title: Go microservice (gRPC + Postgres)
  tags: [recommended, go, backend]
spec:
  owner: platform-team
  type: service
  parameters:
    - title: Service metadata
      required: [name, owner]
      properties:
        name: { type: string, pattern: '^[a-z0-9-]+$' }
        owner: { type: string, ui:field: OwnerPicker }
  steps:
    - id: fetch
      action: fetch:template
      input:
        url: ./skeleton
        values: { name: '${{ parameters.name }}' }
    - id: publish
      action: publish:github
      input:
        repoUrl: github.com?owner=acme&repo=${{ parameters.name }}
    - id: register
      action: catalog:register
      input:
        repoContentsUrl: ${{ steps.publish.output.repoContentsUrl }}

The template should produce, in one click: a repo, a CI pipeline (GitHub Actions or Argo Workflows), a Helm chart wired to ArgoCD, a default SLO.yaml consumed by Sloth or OpenSLO, and a pre-registered entry in the Backstage catalog. Anything less and developers will copy-paste from the team next door.

Build vs. buy: the 2025 landscape

| Option | Best for | Trade-off | |---|---|---| | Backstage (OSS) | 200+ devs, strong platform team, custom needs | High maintenance, plugin churn | | Port | Mid-size orgs wanting fast time-to-value | Less flexible templating, SaaS pricing | | Cortex / OpsLevel | Service ownership & maturity scoring first | Weaker scaffolding than Backstage | | Humanitec + Score | Workload-spec-driven, cloud-agnostic | Steeper conceptual model | | Roll your own | Don't | Don't |

A useful heuristic: if your platform team is smaller than 4 FTE, buy. Backstage's plugin ecosystem is great, but the upgrade cadence (a breaking change roughly every quarter) is a real tax.

Measuring DevEx, not vanity metrics

A catalog with 800 entries means nothing. Track the metrics that correlate with delivery performance:

• DORA four: deployment frequency, lead time for changes, change failure rate, MTTR — instrument via the Backstage DORA plugin or Sleuth/LinearB.
• DevEx framework (Forsgren, Storey, Noda, 2024): feedback loops, cognitive load, flow state. Run a quarterly survey, 10 questions max.
• Golden path adoption rate: % of new services created via templates vs. ad hoc. Target > 80% within 12 months.
• Time to first commit in production for a new hire. We see teams move this from 3 weeks to 2 days after a real IDP rollout.

Anti-patterns we see weekly

• The mandated platform: leadership forces adoption, dev teams comply on paper, shadow tooling thrives. Treat your platform as a product with internal customers who can say no.
• Template sprawl: 40 templates, 3 maintained. Cap at 5–8 golden paths, deprecate aggressively.
• No product manager on the platform team. Without one, the backlog becomes whatever Kubernetes upgrade is screaming loudest.
• Ignoring the inner loop: if make dev takes 4 minutes and Tilt/DevSpace isn't set up, no portal will save you.

A 90-day starter checklist

• [ ] Interview 10 developers across 3 teams. Identify the top 3 painful workflows.
• [ ] Pick one golden path (the most common service type) and ship it end-to-end.
• [ ] Stand up Backstage or Port with the catalog populated from existing repos (catalog-info.yaml discovery).
• [ ] Wire the DORA plugin and publish a baseline.
• [ ] Define the platform team's SLOs toward its users (e.g., template success rate > 95%).
• [ ] Run a monthly DevEx review with stream-aligned team leads.

Key takeaways

• An IDP is golden paths + primitives + interface — not just a portal.
• Backstage wins on flexibility, Port/Cortex on time-to-value; pick based on platform team size.
• Treat the platform as a product: PM, roadmap, internal customers who can opt out.
• Measure DORA and DevEx, not catalog size or ticket count.
• Start with one golden path, ship it well, then expand. Five great templates beat thirty mediocre ones.