Platform Engineering in 2026: Building an Internal Developer Platform Your Teams Will Actually Use

Platform engineering was declared a top strategic technology trend by Gartner in 2023 and has only grown in adoption since. By 2026, the conversation has shifted from whether to build an Internal Developer Platform to how to build one that developers actually want to use rather than work around.

The failure mode for IDP initiatives is building infrastructure that looks impressive in architecture diagrams but adds friction for the teams it is supposed to help. Developers find workarounds, the platform falls behind, and the organization ends up with two systems to maintain: the official platform and the unofficial one.

This post covers what makes the difference between an IDP that gets adopted and one that gets abandoned, with concrete tooling decisions and architecture patterns based on production implementations.

What Problem an IDP Actually Solves

The core problem is cognitive load. As an engineering organization grows, each developer needs to understand an increasing number of systems, tools, and processes to ship a feature: CI/CD pipelines, container registries, Kubernetes namespaces, secrets management, monitoring dashboards, alert routing, database provisioning, and more.

An IDP reduces that cognitive load by abstracting the underlying infrastructure behind a self-service interface. Instead of a developer needing to know how to configure a Kubernetes deployment with the right resource requests, PodDisruptionBudgets, HorizontalPodAutoscalers, and Prometheus annotations, they fill in a form that captures what their service needs and the platform handles the rest.

The business outcome is measurable: teams ship faster, incidents caused by misconfiguration decrease, and senior engineers spend less time on infrastructure support tickets. DORA metrics (deployment frequency, lead time for changes, change failure rate, time to restore service) all improve when the platform removes toil from the delivery path.

The Golden Path: Your Most Important Design Decision

The golden path is the set of tools, processes, and templates that represent the recommended way to build, deploy, and operate a service in your organization. It is not mandatory. It is the path of least resistance, designed so well that developers choose it over building their own solution.

A golden path that covers 80% of use cases and handles them well is more valuable than a flexible framework that can handle 100% of cases but requires deep expertise to configure. Start narrow and expand based on actual demand.

Service template: a repository template with directory structure, Dockerfile, CI/CD pipeline, Kubernetes manifests, and observability hooks already in place
Deployment pipeline: a standard GitHub Actions or GitLab CI workflow that handles build, test, security scan, container push, and deploy to staging, with manual approval gate to production
Observability defaults: Prometheus metrics, structured JSON logging with correlation IDs, and distributed tracing instrumentation built into the template
Secrets access pattern: a standard way to read secrets from Vault or AWS Secrets Manager, so no team is hand-rolling their own secrets management
Database provisioning: a self-service form or IaC module that spins up a properly configured database instance with backups, monitoring, and access credentials pre-wired

Backstage: Service Catalog and Developer Portal

Backstage, open-sourced by Spotify, has become the de facto standard for developer portal and service catalog implementations. It gives you a central place where teams can discover services, see their documentation, track ownership, and trigger self-service workflows.

yaml

# catalog-info.yaml: every service registers itself with Backstage
# Place this in the root of every service repository
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: billing-api
  description: Invoice generation, VAT calculation, and payment processing service
  annotations:
    github.com/project-slug: your-org/billing-api
    backstage.io/techdocs-ref: dir:.
    prometheus.io/alert-manager: "https://alertmanager.internal/alerts?service=billing-api"
    grafana/dashboard-selector: "service=billing-api"
    pagerduty.com/service-id: "P1234AB"
  tags:
    - python
    - fastapi
    - billing
    - postgresql
  links:
    - url: https://grafana.internal/d/billing-api
      title: Grafana Dashboard
    - url: https://runbooks.internal/billing-api
      title: Runbook
spec:
  type: service
  lifecycle: production
  owner: group:billing-team
  system: billing-platform
  dependsOn:
    - component:postgres-billing
    - component:rabbitmq-cluster
  providesApis:
    - billing-api-v2

The catalog registration is the foundational piece. Once every service is in the catalog with accurate ownership and dependency information, you unlock the operational use cases: impact analysis when a shared service has an incident, ownership routing for on-call alerts, and automated deprecation tracking.

Software Templates: Scaffolding New Services

Backstage Software Templates let you define a set of questions (service name, team, programming language, database type) and generate a fully configured repository from a template. This is the mechanism that makes the golden path the default choice.

yaml

# Backstage Software Template definition
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: python-fastapi-service
  title: Python FastAPI Microservice
  description: Creates a production-ready FastAPI service with CI/CD, Kubernetes manifests, and observability
  tags:
    - python
    - fastapi
    - recommended
spec:
  owner: group:platform-team
  type: service

  parameters:
    - title: Service Details
      required: [name, team, description]
      properties:
        name:
          title: Service Name
          type: string
          pattern: '^[a-z][a-z0-9-]*$'
          description: Lowercase, hyphen-separated (e.g. invoice-processor)
        team:
          title: Owning Team
          type: string
          ui:field: OwnerPicker
          ui:options:
            catalogFilter:
              kind: Group
        description:
          title: Service Description
          type: string
        database:
          title: Database
          type: string
          enum: [none, postgresql, redis]
          default: none

  steps:
    - id: fetch-template
      name: Fetch Template
      action: fetch:template
      input:
        url: ./skeleton
        values:
          name: ${{ parameters.name }}
          team: ${{ parameters.team }}
          description: ${{ parameters.description }}
          database: ${{ parameters.database }}

    - id: create-repo
      name: Create GitHub Repository
      action: github:repo:create
      input:
        repoUrl: github.com?repo=${{ parameters.name }}&owner=your-org

    - id: push-content
      name: Push to Repository
      action: github:repo:push
      input:
        repoUrl: github.com?repo=${{ parameters.name }}&owner=your-org

    - id: register-catalog
      name: Register in Backstage
      action: catalog:register
      input:
        repoContentsUrl: ${{ steps['create-repo'].output.repoContentsUrl }}
        catalogInfoPath: /catalog-info.yaml

  output:
    links:
      - title: Repository
        url: ${{ steps['create-repo'].output.remoteUrl }}
      - title: Open in Catalog
        url: ${{ steps['register-catalog'].output.entityRef }}

Self-Service Infrastructure with Terraform and Atlantis

Self-service infrastructure means teams can provision what they need without opening a ticket to the platform team. Terraform modules define opinionated, pre-approved infrastructure components. Atlantis runs Terraform plans and applies via pull requests, keeping the full audit trail in Git.

python

# Example: an opinionated Terraform module for a PostgreSQL database
# Teams call this module with minimal inputs; the module enforces all standards
module "service_database" {
  source = "git::https://github.com/your-org/platform-modules.git//postgresql?ref=v2.3.0"

  # Required inputs: what the team provides
  service_name = "billing-api"
  team         = "billing-team"
  environment  = "production"

  # Optional: override defaults if needed
  instance_class     = "db.t4g.medium"  # default: db.t4g.small
  allocated_storage  = 100              # default: 20 GB

  # Platform enforces these regardless of team input:
  # - encryption at rest (AES-256)
  # - automated backups with 7-day retention
  # - enhanced monitoring enabled
  # - deletion protection enabled in production
  # - parameter group with recommended PostgreSQL settings
  # - security group restricting access to the cluster VPC only
}

The module pattern enforces compliance and security standards without requiring each team to understand them. The platform team owns the module and updates it when standards change. Teams get self-service provisioning without the risk of misconfigured databases in production.

Observability as a Platform Service

Observability should be something every service gets automatically, not something each team sets up from scratch. The platform provides the collection infrastructure (Prometheus, Loki, Tempo) and the service templates include the instrumentation. Teams get dashboards and alerts from day one.

python

# Platform-standard observability instrumentation for FastAPI services
# This goes into the service template; teams do not configure it themselves
from prometheus_client import Counter, Histogram, generate_latest, CONTENT_TYPE_LATEST
from opentelemetry import trace
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.instrumentation.fastapi import FastAPIInstrumentor
import structlog
import time

# Structured logging: every log line is valid JSON with correlation fields
log = structlog.get_logger()

# Standard metrics: every service exposes these
REQUEST_COUNT = Counter(
    "http_requests_total",
    "Total HTTP requests",
    ["method", "path", "status_code", "service"]
)
REQUEST_DURATION = Histogram(
    "http_request_duration_seconds",
    "HTTP request duration",
    ["method", "path", "service"],
    buckets=[0.01, 0.025, 0.05, 0.1, 0.25, 0.5, 1.0, 2.5, 5.0]
)

def setup_telemetry(app, service_name: str):
    # Distributed tracing: export to platform Tempo instance
    provider = TracerProvider()
    provider.add_span_processor(
        BatchSpanProcessor(OTLPSpanExporter(endpoint="http://tempo.platform:4317"))
    )
    trace.set_tracer_provider(provider)
    FastAPIInstrumentor.instrument_app(app)

    # Prometheus metrics endpoint
    @app.get("/metrics")
    def metrics():
        from fastapi.responses import Response
        return Response(generate_latest(), media_type=CONTENT_TYPE_LATEST)

Common Mistakes When Building an IDP

Platform teams make the same mistakes repeatedly. Knowing them in advance saves months of rework:

Building for the platform team, not the users: the platform team knows Kubernetes deeply; most application developers do not and should not need to. Abstract the right things.
Trying to cover every use case from day one: an IDP that handles 5 use cases well is more valuable than one that handles 20 use cases poorly. Ship the golden path first.
Skipping the feedback loop: run regular sessions where application developers show the platform team where they worked around the platform instead of using it. Each workaround is a gap to close.
Treating documentation as optional: the self-service model only works if developers can find out how to use the platform without asking the platform team. Good documentation is not optional.
Mandating adoption before the platform is ready: forcing teams onto a platform that does not yet cover their needs builds resentment that takes years to overcome. Make adoption the obvious choice, not the compulsory one.

Metrics That Show Your Platform Is Working

Platform engineering is an investment, and its return needs to be measurable. These are the metrics that demonstrate business value to both engineering leadership and executives:

Time to production for a new service: from repository creation to first production deployment. A good IDP should bring this from days or weeks to under two hours.
Deployment frequency: how often teams deploy to production. Platforms that remove friction from the deployment pipeline directly improve this DORA metric.
Platform adoption rate: what percentage of services are using the platform's golden path. Target above 80% within 12 months of launch.
Support ticket reduction: how many platform-related support tickets the platform team receives per team per month. Track this before and after launch.
Change failure rate: percentage of deployments that cause a production incident. Standardized deployment pipelines with automated rollback should reduce this significantly.

The Organizational Model

A platform team is not an infrastructure team that has been renamed. The key distinction is the product mindset: the platform team treats application developers as their customers, runs quarterly roadmap reviews based on developer feedback, and measures success by the productivity of the teams they serve rather than the uptime of the infrastructure they run.

In practical terms: a platform team of four engineers can serve 30-50 application developers effectively if the platform covers the common cases well. The ratio breaks down when the platform has too many edge cases or too many manual processes that have not been automated yet.

The IDPs that get abandoned are the ones built by infrastructure teams who were not given the time or the mandate to understand what application developers actually need. The ones that succeed are built by people who sat with application developers and watched where they struggled.