In 2023, “platform engineering” was a buzzword. In 2024, every company announced they were building an Internal Developer Platform. In 2026, we’re finally getting data on which ones actually worked.

The verdict: most IDPs delivered some value, but far fewer delivered on the original promise of dramatically reduced cognitive load for developers. The gap between a functional IDP and a great one is larger than most teams anticipated — and it’s rarely a technical gap.

Photo by Ilya Pavlov on Unsplash

What an IDP Actually Is (And Isn’t)

Before we talk about maturity levels, it’s worth being precise about what we’re measuring.

An Internal Developer Platform is not a developer portal with some dashboards. It’s not Backstage configured with five plugins. It’s not a Helm chart repository.

An IDP is the paved road your developers drive on: the golden paths, the guardrails, the self-service capabilities that let a developer go from “I have an idea” to “this is in production” without filing tickets, waiting for approvals, or configuring infrastructure by hand.

The minimum bar for an IDP: a developer can deploy a new service to production in under an hour without talking to anyone on the platform team.

The IDP Maturity Model

After surveying dozens of engineering organizations, five maturity levels emerge consistently.

Level 1: Ad Hoc Automation

What it looks like: A collection of scripts, Makefiles, and CI/CD templates. There’s a Confluence page someone wrote in 2022 that explains how to set up a new service. Half of it is outdated.

Signs you’re here:

• Onboarding a new developer takes days of setup
• Every team has slightly different deployment pipelines
• “How do I do X?” is answered by asking a senior engineer

What to build next: Standardize your deployment pipeline into a shared template. One pipeline, parameterized for different runtimes. This single change has the highest ROI of anything at this level.

Level 2: Self-Service CI/CD

What it looks like: A shared CI/CD platform (GitHub Actions, GitLab CI, Tekton) with standardized pipeline templates. Developers can deploy without platform team involvement. This is where most teams land after 1-2 years of platform engineering.

Signs you’re here:

• New services follow a template but still require some manual setup
• Infrastructure provisioning (databases, queues, etc.) still requires tickets
• Developers know the happy path but get stuck on edge cases

What to build next: Service catalog + self-service infrastructure provisioning. When a developer creates a service, they should be able to add a PostgreSQL database or an S3 bucket through the same self-service interface.

Level 3: Self-Service Infrastructure

What it looks like: Developers can provision common infrastructure components (databases, caches, queues, storage) through a UI or CLI without involving the platform team. Backstage (or equivalent) provides a service catalog with real-time health and ownership data.

# Developer runs: platform create service my-api
# This generates:
apiVersion: platform.company.com/v1
kind: Service
metadata:
  name: my-api
  team: payments
spec:
  runtime: nodejs-20
  replicas:
    min: 2
    max: 20
  resources:
    preset: standard  # translates to actual CPU/memory limits
  dependencies:
    - type: postgres
      name: my-api-db
      tier: standard
    - type: redis
      name: my-api-cache
      size: small
  observability:
    dashboards: true
    alerts: standard

Signs you’re here:

• Time to first deployment for a new service: under 2 hours
• Developers can find any service’s owner and runbook in under 2 minutes
• Platform team handles exceptions, not the normal case

What to build next: Developer environments and preview environments. This is the unlock for developer velocity — if every PR has a live environment, feedback cycles collapse.

Level 4: Ephemeral Environments and Shift-Left Quality

What it looks like: Every pull request spins up a complete environment: application code, infrastructure, seeded test data. Developers can share links to preview environments for design review, QA, and stakeholder demos. Environments are torn down automatically when PRs close.

Photo by Science in HD on Unsplash

This level is where the compound returns kick in. When testing is fast and cheap, teams test more. When stakeholders can click around on a real feature before it merges, design feedback happens earlier. Quality goes up as cycle time goes down.

# Typical developer workflow at Level 4:
git push origin feature/new-checkout-flow

# Platform automatically:
# 1. Builds the container image
# 2. Provisions: checkout-service, cart-service, payment-service
# 3. Runs database migrations on a seeded snapshot
# 4. Posts preview URL to the PR: https://pr-1234.preview.company.com
# 5. Runs smoke tests, posts results to PR

# Developer shares link with designer: "Can you check the mobile view?"
# Designer clicks around on the real thing, leaves comments on PR
# No staging environment coordination needed

Signs you’re here:

• PR preview environments are table stakes, not a special request
• QA happens before merge, not after
• Developers can reproduce production bugs in isolated environments

What to build next: Golden path templates for non-trivial architectures (event-driven services, ML inference endpoints, data pipelines) and cost observability integrated into the platform UX.

Level 5: Cognitive Load Elimination

What it looks like: The platform has absorbed so much toil that developers genuinely don’t think about infrastructure. They describe what they want at a high level; the platform handles the how.

This is where AI-assisted platform engineering is starting to emerge. Not “AI writes your YAML” (a parlor trick), but platform surfaces that observe production behavior and proactively surface recommendations:

• “Your service is using 40% of its memory limit. I’ve created a PR to reduce the limit and save $380/month. Review?”
• “Your error rate spiked 3x when your dependency user-service deployed v2.1.4. Here’s a rollback option.”
• “Based on your traffic patterns, autoscaling would trigger 20% more efficiently with these settings.”

Signs you’re here:

• New hire deploys to production on day one
• Platform team measures success by developer NPS, not tickets closed
• Developers advocate for the platform instead of routing around it

The Most Common Failure Mode: Platform as Mandate

Here’s the uncomfortable truth: most IDP projects fail not because of bad engineering but because of bad product thinking.

Platform teams build things they think developers need. Developers route around them because the things they actually need are still painful. The platform team then tries to mandate usage (“you MUST use our deploy pipeline”). Developers resent the platform. Leadership wonders why they funded it.

The fix is treating the platform team as a product team, with developers as customers:

• Measure developer satisfaction, not platform metrics
• Do office hours, not just documentation
• Build what removes pain, not what’s technically interesting
• Kill features that nobody uses; don’t maintain them “just in case”

The best platform teams have embedded developer advocates who report pain back to the builders. The worst ones build in isolation and wonder why adoption is low.

What to Actually Do This Quarter

If you’re at Level 1: pick one pipeline template and make it the default. Automate the most painful part of new service creation. Don’t build a portal yet.

If you’re at Level 2: instrument your developer workflows. Find out where people are spending time waiting. The answer will surprise you. Build self-service for the top three pain points.

If you’re at Level 3: build PR environments. The ROI is almost always positive within two quarters. Start with your highest-traffic services.

If you’re at Level 4+: you’ve built something real. Focus on reliability of the platform itself, measure cost impact, and export what you’ve learned back to the community.

Platform engineering done well is invisible. Developers shouldn’t think about it — they should just experience faster, safer shipping. If they’re talking about your platform, something needs to improve.

What level is your team at? I’d genuinely love to hear — find me on GitHub @DevStarSJ.

이 글이 도움이 되셨다면 공감 및 광고 클릭을 부탁드립니다 :)