90% of Us Have Internal Developer Platforms Now. So Why Does Deployment Still Feel Like Filing Taxes?

[maya_builds]

90% of Us Have Internal Developer Platforms Now. So Why Does Deployment Still Feel Like Filing Taxes?

Three months ago, our platform team finally launched our shiny new internal developer platform. Backstage, golden paths, self-service everything. The CTO demo’d it at all-hands, engineering leadership celebrated, and we all nodded along like this was finally going to solve our deployment headaches.

Last week, I watched one of our senior engineers spend 47 minutes trying to deploy a simple feature flag change. Forty. Seven. Minutes. For a configuration update.

When I asked him why he didn’t use the new platform, he just laughed. “Maya, I tried the platform. It’s faster to do it the old way.”

The Adoption Paradox Nobody’s Talking About

Here’s what’s wild: 90% of large enterprises now have internal developer platforms. We beat Gartner’s prediction of 80%. We did it! Platform engineering is here!

So why does deployment still feel like filing taxes in a language you barely speak?

I’ve been thinking about this a lot because I see the exact same pattern in design systems. We build beautiful component libraries, comprehensive documentation, automated tooling. Adoption rate: 12%. Actual usage by teams: even lower.

Having the infrastructure isn’t the same as people actually using it.

What I’m Seeing From the Design Side

Our design system has 247 components. The platform team estimates we have 300+ “golden path” workflows. But here’s the thing:

• Developers still copy-paste old deployment scripts because “it works”
• Product teams bypass the platform when they’re on deadline (which is always)
• The platform team is underwater responding to support tickets instead of improving features
• We measure “adoption” by number of components in Figma libraries, not by actual usage

Sound familiar?

The platform team keeps adding features nobody asked for. Meanwhile, the three things developers actually need—faster build times, simpler config, and one-click rollback—are “on the roadmap.”

The Real Cost: Maintenance Hell

Our platform team spent 8 months building this thing. Eight months! They’re exhausted. Half the original team has rotated off to other projects because maintaining a homegrown Backstage instance is basically a second full-time job.

Breaking plugin updates. Complex upgrades. Documentation that falls out of date within weeks.

One engineer told me: “We built an impressive storefront with empty shelves.”

The Questions I Can’t Stop Asking

1. Why do high adoption stats not translate to happy developers? Are we measuring the wrong things?

2. When does a platform become just another bottleneck? The old way was slow, but at least it was predictable. Now we have “self-service” that requires three Slack messages and a ticket.

3. Who’s building these platforms FOR? Senior engineers who already know the systems? Or junior devs who just want to ship code without reading 50 pages of documentation?

4. Is DIY dead? I keep hearing about teams switching from self-hosted Backstage to commercial solutions. Are we all going through the same painful realization?

What I’d Do Differently (If Anyone Asked the Designer)

If I could rebuild our platform with a design lens:

• Start with user research: What do developers actually need? Not what we think they need.
• Design for the 90% use case first. Golden paths should feel like downhill skiing, not rock climbing.
• Measure satisfaction, not just usage. An engineer using the platform while cursing is not a success story.
• Build with junior developers in mind. If it requires tribal knowledge, it’s not self-service.
• Co-create with users, not for them. Platform team can’t be an ivory tower.

Tell Me I’m Not Crazy

Am I overthinking this? Is your platform experience better than mine?

Or is everyone else also sitting in meetings nodding along about “platform success” while secretly using the old deployment scripts when nobody’s watching?

What’s your internal platform adoption story? Are we celebrating too early, or am I just working at the wrong company?

---

Full disclosure: I still love the idea of platforms. I just think we’re solving the wrong problems. Or maybe solving the right problems the wrong way. Or both.

[eng_director_luis]

Maya, you’re absolutely not crazy. You’re describing what I see every day from the engineering leadership side—and honestly, your design systems parallel is spot on.

The Structural Problems Are Real

Here’s the thing: platforms solve genuine problems. Before we built ours, we had:

• Seven different CI/CD tools across teams (not an exaggeration)
• Security policies enforced inconsistently because every team had different tooling
• Two-day waits for Kubernetes cluster access because everything went through a bottleneck team
• 40% of developer time spent on YAML configuration and troubleshooting

Those are structural problems. They don’t go away with better Slack coordination or more wiki pages. You need shared abstractions.

But You’re Right About the Adoption Gap

Where you’re 100% right: having a platform doesn’t mean people use it.

We rolled out our IDP six months ago. Usage stats? 73% of teams have “onboarded.” Actual daily active users? Maybe 30%. And of those, half are the platform team testing their own features.

The honest truth? Senior engineers bypass it when they’re under pressure. Junior engineers don’t know it exists because it’s not in onboarding docs. Product teams treat it like a compliance checkbox.

The Measurements Are Lying to Us

Your question about metrics hit me hard. We measure:

• Number of services registered in the catalog
• Number of golden path templates created
• Number of API calls to the platform

We don’t measure:

• Developer satisfaction with deployment experience
• Time saved vs. old workflows (net, not gross)
• How many people actively choose the platform vs. being forced to use it

We’re measuring activity, not outcomes. And leadership celebrates the activity metrics because they’re going up and to the right.

The Cultural Change Nobody Planned For

The dirty secret about platform engineering: the technical transformation is 30% of the work. The cultural transformation is 70%.

We spent 8 months building the platform. We spent zero months preparing teams for how to use it, why they should care, or what problems it actually solves for them (not for us).

Your point about building for senior engineers? Guilty as charged. Our platform team is all principal+ engineers. They built a platform that makes sense to principal+ engineers. Everyone else is lost.

What’s Actually Working (When It Works)

The teams that successfully adopted our platform have one thing in common: we embedded platform team members with them for 2-3 weeks.

Not “office hours” or “support tickets.” Full embedded work. Pairing sessions. Watching them actually use the platform. Fixing the sharp edges immediately.

After those embedded engagements:

• Onboarding time: 5 days → 4 hours
• Deployment frequency: 2x per week → 10x per week
• Developer eNPS: 30 → 75

Those are the numbers I wish we’d baked into our success criteria from day one.

The Hard Truth

You asked “are we celebrating too early?”

Yes. We absolutely are.

90% adoption means 90% of enterprises have platform teams. It doesn’t mean 90% have successful platforms. It definitely doesn’t mean 90% have developers who love their platforms.

We built the infrastructure. Now we have to do the harder work: change management, user research, iterative improvement based on actual usage patterns.

Your five design principles at the end? I’m literally copying those into our Q2 planning doc. “Build with junior developers in mind” should be tattooed on every platform team’s wall.

The platform is a product. We just forgot to treat it like one.

[product_david]

This thread is giving me flashbacks to every internal platform review meeting I’ve sat through.

Maya, your “filing taxes” metaphor is painfully accurate. And Luis, those metrics you mentioned? I see the same deck every quarter. Green checkmarks everywhere. Engineers miserable.

The Product Manager’s Dilemma

Here’s what I see from the product side:

Platform teams don’t think about product-market fit for internal tools.

When we launch a customer-facing product, we obsess over:

• Who is the user?
• What job are they trying to do?
• What alternatives exist?
• How do we measure adoption vs. satisfaction?
• What’s the opportunity cost of building this vs. buying it?

But internal platforms? Nope. “Build it and they will come” is somehow still the operating model in 2026.

The New Bottleneck Problem

Luis mentioned structural bottlenecks the platform was supposed to fix. Totally valid.

But here’s what I’m seeing: we traded one bottleneck for another.

Before: Wait 2 days for DevOps team to provision infrastructure.

After:

1. Read 50 pages of platform documentation
2. Figure out which of the 300 golden paths applies to your use case
3. Realize none of them quite fit
4. Open a Slack thread asking for help
5. Get told to “file a ticket”
6. Wait 3 days for platform team to customize the template
7. Finally deploy

Net result? Still waiting days. Just with more steps and more complexity.

The ROI Question Nobody Asks

I did some back-of-napkin math on our platform investment:

• Platform team: 8 engineers × 8 months build + 4 engineers ongoing = ~$3.2M in first year
• Developer time saved: Maybe 2 hours/week per engineer who actively uses it
• Engineers actively using it: ~30 out of 120
• Annual value: 30 × 2 × 50 weeks × $100/hour = $300K

We spent $3.2M to save $300K. And that’s before counting the frustration cost of the 90 engineers who avoid it.

Luis talked about embedded platform engineers getting great results. That’s the model! But it doesn’t scale, which means we’re back to the bottleneck problem.

What I’d Ask Platform Teams

If I could force every platform team to answer these questions before building:

1. Who is your user? “Developers” is not an answer. Junior devs deploying their first service? Senior SREs managing production? Different needs entirely.

2. What is your alternative? What happens if teams don’t use your platform? Because that’s your real competition, not the hypothetical perfect world.

3. How do you measure success? And I mean actual success, not “number of templates created.”

4. Buy vs. build? Backstage-as-a-service (Roadie, etc.) costs $100K/year. Your platform team costs $1.6M/year. What’s the honest trade-off?

The Hard Product Truth

Internal tools need product management. Not project management. Not feature factories. Actual product management.

• User research with real developers (not just surveys)
• Rapid iteration based on feedback
• Ruthless prioritization of high-value, high-frequency workflows
• Willingness to kill features that aren’t working

Maya’s “co-create with users” point is exactly this. Platform teams that win are the ones that treat developers as customers, not beneficiaries of their technical brilliance.

Otherwise, we’re just building expensive shelfware.

[cto_michelle]

David’s ROI calculation just gave me heartburn, but he’s not wrong. As someone who’s made the platform investment decision at two different companies, I need to add the CTO perspective here.

The DIY Trap Is Real

We tried the DIY Backstage route at my last company. Full commitment. Dedicated team. Best intentions.

Reality check:

• 6 months to “launch” (really more like 9 when you count all the delays)
• Another 6 months fixing breaking changes from plugin updates
• Adoption plateaued at 15%
• Platform team burned out and started looking for new jobs

That “impressive storefront with empty shelves” quote? That was literally us.

At my current company, we made a different choice: we bought instead of built. Roadie for Backstage hosting. Port for internal developer portal. Humanitec for application management.

Cost? ~$250K annually.
Value? We skipped directly to delivering business value instead of maintaining commodity infrastructure.

The Build vs. Buy Calculus Has Changed

Here’s what shifted my thinking:

2023: “We’re special. Our infrastructure is unique. We need custom solutions.”

2026: “90% of what we need is commodity. The 10% that’s unique doesn’t require us to own the platform itself.”

Luis mentioned embedded platform engineers getting results. That’s exactly the point—those engineers should be focused on your unique golden paths, not on updating Backstage plugins or fixing OAuth integration for the fifth time.

The Real Platform Maturity Question

Maya asked if we’re celebrating too early. I think we’re celebrating the wrong thing entirely.

What we’re celebrating: “We have a platform! We have a team! 90% adoption!”

What we should be asking: “Are we delivering the outcomes the business needs?”

Because here’s the strategic truth: the platform is not the product. The platform enables the product.

If your platform team is spending 70% of their time on maintenance and 30% on value delivery, you’ve got the ratio backwards. And that’s exactly what DIY platforms create.

Where DIY Makes Sense (And Doesn’t)

I’m not anti-DIY on everything. But you need to be honest about where you’re differentiated:

Build:

• Company-specific golden paths and templates
• Integration with your unique internal systems
• Workflows that reflect your actual org structure and processes

Buy:

• Backstage hosting and maintenance
• Plugin updates and compatibility
• Authentication and authorization infrastructure
• Service catalog and discovery
• Developer portal UI/UX

The companies winning at platform engineering are the ones that recognize this distinction.

The Culture Part Nobody Funded

Luis hit on something critical: cultural transformation is 70% of the work.

At my current company, we budget platform adoption like we budget change management:

• Embedded platform engineers (as Luis described)
• Lunch-and-learns every two weeks
• Office hours, but actually staffed and promoted
• Success metrics tied to developer satisfaction, not feature count

That costs money. Real money. But it’s the only way the technical investment pays off.

David’s right that internal tools need product management. But they also need marketing, support, and customer success. We just call them different things internally.

The Uncomfortable Executive Question

Here’s what I ask myself every quarter:

“If this platform team quit tomorrow and we had to start over, would we rebuild what we have or buy something off the shelf?”

For most companies, the honest answer is “buy.” Which tells you something about whether the DIY path was the right choice in the first place.

Moving Forward

If you’re in the DIY trap right now:

1. Acknowledge the sunk cost. It doesn’t matter how much you invested; it matters whether continuing that path delivers value.

2. Calculate the actual ROI (like David did). Be brutally honest about adoption and satisfaction.

3. Consider hybrid: Keep the team, change what they work on. Buy commodity infrastructure, focus on company-specific value.

4. Measure outcomes, not outputs. Developer satisfaction. Time to production. Deployment frequency. Not “number of golden paths.”

The platform engineering movement is real and valuable. But we’re at the point where maturity means making strategic choices about build vs. buy, not just celebrating that we have a platform team.

Maya, your instincts are exactly right. Having the infrastructure isn’t enough. We need to deliver outcomes that developers actually care about. And sometimes that means admitting that DIY was the wrong path.

[vp_eng_keisha]

This conversation is giving me life because it’s so honest about the gap between platform adoption stats and platform adoption reality.

Michelle’s build vs. buy framework and David’s ROI math are both crucial. But I want to zoom in on something Maya touched on that I think is the root cause: who are we building these platforms for?

The Inclusive Design Problem

Here’s what I see as a VP Engineering: platforms designed by senior engineers, for senior engineers, measured by senior engineering metrics.

But here’s who actually needs to use them:

• New college grads on their first team
• Engineers who joined via acquisition and don’t know our infrastructure
• Contract engineers ramping up quickly
• Product engineers who just want to ship features, not learn Kubernetes
• Engineers from non-infrastructure backgrounds

If your platform requires tribal knowledge, you’ve failed at self-service.

The Co-Design Approach That Actually Works

At my current company, we took a different approach when building our platform:

Step 1: Interview the most junior engineers on every team.

Not the tech leads. Not the principal engineers. The people who joined in the last 6 months.

What we learned:

• Our “intuitive” service catalog was completely opaque to newcomers
• Golden paths made sense if you already understood our infrastructure
• Documentation assumed context that only long-tenured engineers had
• The platform optimized for edge cases, not for the 80% use case

Step 2: Co-design with diverse user groups.

We formed a platform advisory group:

• 2 engineers with <1 year experience
• 2 product engineers (not infrastructure background)
• 2 SREs
• 1 data engineer
• 1 mobile engineer

Every feature went through this group first. If the junior engineers couldn’t figure it out, we redesigned it.

Step 3: Embed platform engineers with product teams.

Luis mentioned this—it’s transformational. But here’s the key: the platform engineers are there to learn, not just to teach.

Our embedded engineers spent 2 weeks:

• Pairing with product engineers on actual work
• Watching them struggle with the platform (and taking notes)
• Fixing sharp edges in real-time
• Building empathy for users’ actual workflows

The Metrics That Actually Matter

David’s ROI calculation was brutal but necessary. Here’s what we measure that actually correlates with satisfaction:

Instead of: “Number of services onboarded”
We measure: “Time from ‘I want to deploy’ to ‘it’s in production’” (p50, p90, p99)

Instead of: “Golden path adoption rate”
We measure: “% of engineers who would recommend the platform to a colleague” (eNPS)

Instead of: “Platform team velocity”
We measure: “# of unblocked deployments per week” (removing friction, not adding features)

The shift in perspective? The platform team succeeds when they make themselves invisible.

When developers don’t think about the platform, just about their work—that’s success. When they have to think about it, that’s where friction lives.

The Accessibility Parallel

Maya, your design systems parallel resonates because this is fundamentally an accessibility problem.

If your platform only works for expert users, you’ve built something inaccessible. And inaccessible tools get abandoned or worked around.

The best platforms I’ve seen:

• Progressive disclosure: Simple path for common cases, advanced options for power users
• Sensible defaults: Most deployments should work with zero configuration
• Clear error messages: Written for humans, not for the platform team
• Escape hatches: When the golden path doesn’t work, there’s a clear alternative

The Organizational Design Part

Luis said cultural transformation is 70% of the work. I’d go further: org structure is destiny for platform teams.

If your platform team reports up through infrastructure and has zero product management, you get infrastructure-centric platforms.

What works:

• Platform team structured like a product team (PM, designers, engineers, support)
• KPIs tied to developer satisfaction and productivity, not platform features shipped
• User research budget and dedicated researcher time
• Support rotation where platform engineers help product teams directly

The platform team isn’t a service provider. They’re a product team whose customer happens to be internal.

Where I’ve Seen This Work

Our current platform went from 15% adoption to 85% active usage (not just registration) by:

1. Redesigning for junior engineers first: If it’s easy for them, it’s easy for everyone
2. Co-design with diverse users: Multiple backgrounds and experience levels
3. Measuring satisfaction over activity: eNPS went from 30 to 75
4. Embedding to learn, not just teach: Bi-directional knowledge transfer
5. Building for the 80% case: Power users can handle complexity; beginners can’t

The result? Our platform team spends 70% of their time on value-adding features and 30% on maintenance. Michelle’s point about getting that ratio right is exactly right.

Maya’s Original Question

You asked if we’re celebrating too early. I think the answer is: we’re celebrating the wrong milestone.

90% of enterprises having platforms is like saying 90% of companies have design systems. Cool—but are developers happy? Are they productive? Are they choosing the platform or being forced into it?

The real milestone isn’t adoption. It’s when developers stop talking about the platform because it just works.

Your five principles at the end are perfect. I’d add one more:

6. Build for your least experienced user first. If it works for them, it works for everyone. If it only works for experts, it’s not a platform—it’s an exclusive club.

Keep pushing these questions, Maya. This is exactly the conversation platform teams need to hear.