Dev Note

Platform Engineering in 2026: Building Internal Developer Platforms That Teams Actually Use
Platform engineering has become one of the fastest-growing disciplines in software infrastructure. The pitch is compelling: instead of every team reinventing CI/CD, observability, secrets management, and deployment workflows, a dedicated platform team builds a “paved road” that makes the right way also the easy way.
But most Internal Developer Platforms (IDPs) fail — not technically, but in adoption. They become elaborate systems that developers route around rather than embrace. This post is about what separates platforms that get adopted from those that gather dust.
Photo by Alvaro Reyes on Unsplash
The Platform Engineering Mental Model Shift
The fundamental error most platform teams make is building infrastructure for themselves, not products for their customers.
Platform engineering is product engineering. Your customers are developers. Their NPS score is your metric.
This means:
Developer interviews before building features (yes, really)
Deprecation warnings and migration paths when APIs change
Documentation as a first-class artifact (not an afterthought)
SLAs and on-call rotations for platform services
Feature flags and gradual rollouts when introducing changes
The teams that get this right think of themselves as running a product company where their only customer segment is internal developers.
The Core Platform Capabilities
A mature IDP typically provides:
Capability
      Tools (2026)
      Outcome
    
Self-service provisioning
      Backstage, Port, Cortex
      New service in <30 min
    
CI/CD pipelines
      Dagger, GitHub Actions, Tekton
      Consistent builds
    
Secrets management
      Vault, External Secrets Operator
      No secrets in code
    
Observability
      OpenTelemetry, Grafana Stack
      One dashboard per service
    
Environments
      Crossplane, Terraform
      Ephemeral PR environments
    
Security scanning
      Trivy, Semgrep, SAST
      Security by default
    
Cost attribution
      OpenCost, Kubecost
      Per-team cost visibility
    
The key insight: you don’t need all of these on day one. Start with the one capability that causes the most developer pain.
The Portal: Backstage in Practice
Backstage remains the dominant IDP portal framework in 2026, now with a more stable plugin ecosystem and improved performance.
Setting Up Backstage
# app-config.yaml
app:
  title: Acme Developer Platform
  baseUrl: https://backstage.acme.internal
backend:
  baseUrl: https://backstage.acme.internal
  listen:
    port: 7007
  database:
    client: pg
    connection:
      host: ${POSTGRES_HOST}
      port: ${POSTGRES_PORT}
      user: ${POSTGRES_USER}
      password: ${POSTGRES_PASSWORD}
      database: backstage
integrations:
  github:
    - host: github.com
      token: ${GITHUB_TOKEN}
catalog:
  rules:
    - allow: [Component, System, API, Resource, Location, Group, User]
  locations:
    # Auto-discover catalog-info.yaml from all repos
    - type: github-discovery
      target: https://github.com/acme-corp
      rules:
        - allow: [Component, API, System]
Catalog Entity Definition
Every service should have a catalog-info.yaml in its repo:
# catalog-info.yaml (in your service repo)
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: payment-service
  description: Handles payment processing and billing
  annotations:
    github.com/project-slug: acme-corp/payment-service
    backstage.io/techdocs-ref: dir:.
    datadoghq.com/dashboard-url: https://app.datadoghq.com/dashboard/abc-123
    pagerduty.com/service-id: P12AB3C
    sonarqube.org/project-key: payment-service
  tags:
    - payments
    - critical
    - pci-dss
  links:
    - url: https://runbooks.acme.internal/payment-service
      title: Runbooks
      icon: book
spec:
  type: service
  lifecycle: production
  owner: group:payments-team
  system: billing-system
  providesApis:
    - payment-api-v2
  consumesApis:
    - fraud-detection-api
    - notification-api
  dependsOn:
    - resource:payments-postgres
    - resource:payments-redis
Custom Scaffolder Templates
The killer feature: self-service service creation that enforces standards:
# template.yaml — in your platform templates repo
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: new-go-service
  title: New Go Microservice
  description: Creates a production-ready Go service with all platform integrations
spec:
  owner: platform-team
  type: service
  
  parameters:
    - title: Service Details
      required: [name, owner, description]
      properties:
        name:
          title: Service Name
          type: string
          pattern: '^[a-z][a-z0-9-]*$'
          description: Lowercase, hyphen-separated (e.g., payment-processor)
        owner:
          title: Owning Team
          type: string
          ui:field: OwnerPicker
          ui:options:
            catalogFilter:
              - kind: Group
        description:
          title: Description
          type: string
        pciScope:
          title: In PCI Scope?
          type: boolean
          default: false
          
    - title: Infrastructure
      properties:
        database:
          title: Database
          type: string
          enum: [none, postgres, mysql, mongodb]
          default: none
        cache:
          title: Cache Layer
          type: string
          enum: [none, redis, memcached]
          default: none
        minReplicas:
          title: Minimum Replicas
          type: integer
          default: 2
          minimum: 1
          maximum: 10
  
  steps:
    - id: fetch-template
      name: Fetch Base Template
      action: fetch:template
      input:
        url: ./skeleton
        values:
          name: $
          owner: $
          description: $
          database: $
          minReplicas: $
    
    - id: create-repo
      name: Create GitHub Repository
      action: github:repo:create
      input:
        name: $
        org: acme-corp
        visibility: private
        defaultBranch: main
        requireCodeOwners: true
        
    - id: push-to-repo
      name: Push Template
      action: github:repo:push
      input:
        repoUrl: github.com/acme-corp/$
        
    - id: create-argocd-app
      name: Register in ArgoCD
      action: http:backstage:request
      input:
        method: POST
        path: /api/proxy/argocd/api/v1/applications
        body:
          apiVersion: argoproj.io/v1alpha1
          kind: Application
          metadata:
            name: $
          spec:
            project: default
            source:
              repoURL: https://github.com/acme-corp/$
              path: deploy/
            destination:
              server: https://kubernetes.default.svc
              namespace: $
  
  output:
    links:
      - title: Repository
        url: $
      - title: ArgoCD Application
        url: https://argocd.acme.internal/applications/$
The Golden Path: Making Right Things Easy
The “golden path” concept is central to good platform engineering. It means providing one well-maintained, well-documented route to production that covers 80% of use cases.
Dockerfile Standard
Instead of every team writing their own Dockerfile:
# platform/base-images/go-service/Dockerfile
# Teams inherit from this rather than writing from scratch
FROM golang:1.24-alpine AS builder
WORKDIR /app
# Cache dependencies layer separately
COPY go.mod go.sum ./
RUN go mod download
COPY . .
# Build with reproducibility flags
RUN CGO_ENABLED=0 GOOS=linux GOARCH=amd64 \
    go build \
    -ldflags="-w -s -X main.Version=${VERSION} -X main.BuildTime=${BUILD_TIME}" \
    -trimpath \
    -o /service \
    ./cmd/server
# Security: run as non-root
FROM gcr.io/distroless/static:nonroot AS runtime
COPY --from=builder /service /service
# Platform standard: health check on /health
EXPOSE 8080
USER nonroot:nonroot
ENTRYPOINT ["/service"]
HEALTHCHECK --interval=30s --timeout=10s --start-period=5s --retries=3 \
    CMD ["/service", "healthcheck"]
Helm Chart Standard
# platform/charts/go-service/values.yaml
# Sensible defaults that teams override minimally
replicaCount: 2
image:
  repository: ""  # Required
  tag: ""         # Required
  pullPolicy: IfNotPresent
service:
  type: ClusterIP
  port: 8080
resources:
  requests:
    cpu: 100m
    memory: 128Mi
  limits:
    cpu: 500m
    memory: 512Mi
autoscaling:
  enabled: true
  minReplicas: 2
  maxReplicas: 10
  targetCPUUtilizationPercentage: 70
# Platform defaults: always enabled
podDisruptionBudget:
  enabled: true
  minAvailable: 1
serviceAccount:
  create: true
  automount: false
# Security defaults: always enforced
podSecurityContext:
  runAsNonRoot: true
  runAsUser: 65534
  fsGroup: 65534
securityContext:
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    drop: [ALL]
Self-Service Environments with Crossplane
One of the highest-leverage platform capabilities: giving developers ephemeral environments for every PR.
# XRD: Composite Resource Definition for dev environments
apiVersion: apiextensions.crossplane.io/v1
kind: CompositeResourceDefinition
metadata:
  name: xdevenvs.platform.acme.io
spec:
  group: platform.acme.io
  names:
    kind: XDevEnv
    plural: xdevenvs
  claimNames:
    kind: DevEnv
    plural: devenvs
  versions:
    - name: v1alpha1
      served: true
      referenceable: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                serviceName:
                  type: string
                  description: "Name of the service being developed"
                imageTag:
                  type: string
                  description: "Docker image tag to deploy"
                ttlHours:
                  type: integer
                  default: 24
                  description: "Hours before automatic cleanup"
                resources:
                  type: object
                  properties:
                    preset:
                      type: string
                      enum: [small, medium, large]
                      default: small
# Developer creates a dev environment with one YAML
apiVersion: platform.acme.io/v1alpha1
kind: DevEnv
metadata:
  name: payment-service-pr-1234
  namespace: dev-environments
spec:
  serviceName: payment-service
  imageTag: pr-1234-abc123
  ttlHours: 48
  resources:
    preset: small
Crossplane provisions the namespace, database clone, secrets, ingress — the whole stack — automatically.
Measuring Platform Success
The DORA Metrics Connection
Platform teams should track how their work impacts the four DORA metrics:
Metric
      Target (Elite)
      How Platforms Help
    
Deployment Frequency
      Multiple/day
      Automated pipelines reduce friction
    
Lead Time for Changes
      < 1 hour
      Self-service provisioning
    
Change Failure Rate
      < 5%
      Consistent quality gates
    
Recovery Time
      < 1 hour
      Standardized rollback procedures
    
Developer Experience Surveys
Run quarterly DX surveys. Keep them short (5 questions max):
How satisfied are you with your ability to deploy code? (1-5)
How long does it take to set up a new service from scratch? (< 1hr / 1-4hr / half day / > 1 day)
What is your biggest friction point today? (open text)
Which platform capability would you most like to see improved? (list)
Net Promoter Score: How likely are you to recommend our platform to a new hire? (0-10)
Track NPS over time. A platform NPS of 30+ is excellent; 0 means you have serious problems; negative means developers actively work around you.
Common Platform Engineering Pitfalls
1. Building Before Validating
The #1 mistake: spending 6 months building a service catalog that developers don’t ask for while teams are actually drowning in manual certificate renewals.
Fix: Interview 5-10 developers. Ask “What takes you the most time?” and “What do you manually do that you think should be automated?” Build the top answer first.
2. Forced Adoption (“Everyone Must Use This”)
Mandating platform use before it’s good enough destroys trust permanently.
Fix: Make the golden path genuinely easier than the alternative. If you need mandates, your product isn’t good enough yet.
3. No Backwards Compatibility
Changing APIs or pipelines without notice breaks developer trust.
Fix: Semantic versioning for platform APIs. Deprecation warnings 60 days before removal. Migration guides for every breaking change.
4. Platform Team as Bottleneck
If every infra request goes through the platform team, you’ve just recreated the ops bottleneck with a new name.
Fix: Build self-service first. Platform team should be building tools that remove themselves from the critical path.
Conclusion
Platform engineering done right creates compounding returns: every hour the platform team invests in removing friction pays dividends across every developer team, every sprint, indefinitely.
But the investment only pays off if developers use the platform. That means treating it like a product, measuring adoption and satisfaction, and being willing to delete features that don’t get used.
The best platform teams I’ve seen think of themselves as developer advocates who happen to own infrastructure. The worst think of themselves as infrastructure owners who graciously serve developers. The mindset difference produces radically different outcomes.
Start small. Pick one pain point. Solve it completely. Then pick the next one.
Building a platform team? I’d love to hear about your experience — what worked, what didn’t.

Platform Engineering in 2026: Building Internal Developer Platforms That Teams Actually Use

댓글