Gartner Predicted 80% Platform Engineering Adoption by 2026, But We're at 55%—Are We Overhyping Portals While Underinvesting in Platform Fundamentals?

General
1

Let’s talk about the gap between hype and reality in platform engineering.

The Gartner Prediction vs. Reality

  • 2022: 45% of organizations had platform engineering practices
  • 2025: 55% (only 10% growth)
  • 2026 Gartner prediction: 80% adoption

To hit 80%, we’d need 25% growth in one year. That’s not happening.

My Observation

I see a lot of Backstage installations. But how many are actually production-ready with real developer adoption?

Critical Question

Are teams confusing “installing Backstage” with “building a platform”?

Portal ≠ Platform

Portal is the interface. Platform is the underlying capabilities:

  • Automated provisioning (infrastructure, databases, services)
  • Golden paths (templates, scaffolding, guardrails)
  • Self-service operations (deployments, rollbacks, scaling)
  • Observability integration (metrics, logs, traces)
  • Security by default (secrets management, auth, compliance)

You can have a beautiful portal with no automation behind it. That’s a dashboard, not a platform.

The Pattern I See

Every platform engineer has seen this:

  1. Team installs Backstage
  2. Spends 6 months customizing UI
  3. Launches to low adoption
  4. Discovers developers need automation, not documentation

Industry Reflection

Are we repeating DevOps mistakes? In 2015, everyone “did DevOps” by renaming Ops team to DevOps. We focused on tools (Jenkins, Docker) instead of outcomes (deployment frequency, MTTR).

Is platform engineering making the same mistake? Focusing on portals instead of developer productivity?

My Take

Portal is necessary but not sufficient. Standing up Backstage UI is easy. Keeping platform relevant over time—with fresh docs, maintained templates, working automation—that’s hard.

The Question

Are we overhyping portals while underinvesting in platform fundamentals?

2

Classic Technology Hype Cycle

Michelle, we’re in the “trough of disillusionment” phase. This is expected.

Innovation Adoption Curve

  • 2.5% Innovators (early Backstage adopters, 2020-2021)
  • 13.5% Early Adopters (platform engineering pioneers, 2022-2023)
  • 34% Early Majority (current phase, 2024-2025)
  • 34% Late Majority (2026-2028)
  • 16% Laggards (2029+)

55% is Actually Strong

We’re at early majority phase. Enterprise adoption is always slower than predictions—that’s normal.

Gartner’s 80% prediction was optimistic. 55% by 2025 is solid progress.

But I Agree: Portal ≠ Platform

You’re absolutely right that many teams install Backstage and call it done. That’s not platform engineering—that’s portal installation.

Platform Engineering Requires Product Thinking

Real platform engineering means:

  • Understanding developer pain points
  • Building automation to solve them
  • Measuring outcomes (cycle time, MTTR, developer satisfaction)
  • Iterating based on feedback

Portal is just the UI layer.

Focus on Outcomes, Not Tools

Better metrics than “adoption percentage”:

  • Deployment frequency (are golden paths reducing friction?)
  • Time to production (are scaffolders helping?)
  • Developer satisfaction (quarterly surveys)

If those metrics improve, platform is working—regardless of whether you have a portal.

My Take

We’re not overhyping portals. We’re undereducating about what platform engineering actually means.

Portals are useful, but they’re 20% of platform engineering, not 80%.

3

Validation: I’ve Seen This Pattern

Michelle, you’re describing exactly what I see in the wild.

Many “Platform Teams” Are Just Maintaining Backstage

Instead of:

  • Building self-service automation
  • Creating golden paths
  • Reducing cognitive load
  • Improving developer productivity

They’re:

  • Upgrading Backstage versions
  • Debugging plugin conflicts
  • Customizing UI components
  • Managing infrastructure

Platform Engineering Requires Product Thinking

This is the key insight many teams miss. Platform engineering isn’t an SRE function—it’s a product function.

You need:

  • Product manager (not just tech lead)
  • User research (talk to developers weekly)
  • Roadmap (prioritize based on impact)
  • Metrics (measure outcomes, not outputs)

Our Platform Includes More Than Portal

  • CI/CD (automated pipelines, deployment)
  • Observability (metrics, logs, traces)
  • Infrastructure as Code (Terraform modules, AWS scaffolding)
  • Security (secrets management, SIEM integration)
  • Developer environments (local dev, staging, production parity)

Portal is just the UI layer that surfaces this automation.

Without Underlying Golden Paths, Portal Is Empty Shell

If scaffolder templates don’t actually provision working infrastructure, they’re useless. If catalog shows services but can’t deploy them, it’s just documentation.

My Suggestion

Invest in automation first, portal second. Or portal becomes an empty promise.

Platform team needs PM mindset, not just engineering skills.

4

Ground Truth: We Fell Into This Trap

Michelle, embarrassingly, you’re describing my team’s journey.

What We Did Wrong

Year 1: Focused on portal—beautiful UI, comprehensive catalog, custom plugins
Year 2: Launched to 15% adoption because we hadn’t built underlying automation

The Learning

Portal shows what exists. Platform enables what’s possible.

Example: Scaffolder Templates

We built scaffolder templates for “create new service.” Looked great in demos. But:

  • Templates generated code, but didn’t provision infrastructure
  • Developers still needed to manually create databases, configure DNS, set up CI/CD
  • Template saved 20 minutes, but manual setup took 2 days

Result: Developers ignored scaffolder, continued manual process.

Year 2 Pivot: Automation First

We rebuilt:

  1. Automated infrastructure provisioning (Terraform modules)
  2. Automated CI/CD setup (GitHub Actions templates)
  3. Automated observability (Datadog dashboards, alerts)
  4. THEN updated scaffolder to trigger automation

Now: Template generates code AND provisions everything. Developers go from zero to deployed service in 1 hour.

Adoption jumped from 15% to 60%.

Portal Is Interface to Automation

Without automation, portal is documentation. With automation, portal is enablement.

My Advice to Newer Platform Teams

Focus on developer pain points:

  • What takes the longest? (Infrastructure provisioning?)
  • What requires the most expertise? (Security configuration?)
  • What blocks new hires? (Environment setup?)

Automate those first. Add portal later.

5

Design Thinking: Form Over Function Problem

This is classic “form over function”—beautiful UI with weak backend.

Comparison to Design Systems

I’ve seen design systems with:

  • Gorgeous Storybook documentation
  • Comprehensive component library
  • Beautiful UI examples

But no actual components that developers needed. Result: zero adoption.

Portal = Form, Automation = Function

You can’t have form without function. Portal without automation is like design system without components.

User Research: What Do Developers Actually Need?

Probably not another dashboard. Probably:

  • Faster environment setup
  • Self-service database provisioning
  • One-click deployments
  • Automated rollbacks

The “Remove Portal” Test

If you removed the portal tomorrow, would developers notice? Or would work continue because real value is in underlying automation?

If work continues, portal is nice-to-have. If work stops, portal is critical.

My Startup Experience

We built beautiful UI with weak backend. Looked impressive in investor demos. But when developers tried to use it, it didn’t work.

Result: Startup failed (not entirely due to this, but it contributed).

Learn From My Mistakes

  1. Talk to developers first (what problems do they have?)
  2. Build automation to solve those problems
  3. Build portal to surface automation
  4. Measure outcomes (time saved, satisfaction)

Don’t build portal first and hope problems appear.