Building Internal Developer Platforms That Developers Actually Want to Use: Lessons from High-Performing Platform Teams

Why Most Internal Platforms Fail

Companies like Spotify, Netflix, and Amazon operate at a scale where engineering velocity is paramount. To accelerate delivery, many organizations build Internal Developer Platforms (IDPs)—self-service layers that streamline infrastructure management, CI/CD, security, and deployment pipelines.

But here’s the problem: Most IDPs fail not because of bad technology—but because developers don’t want to use them.

According to a 2024 report from Humanitec, over 60% of internal platforms suffer from poor developer adoption. Gartner echoes this concern, highlighting that “developer-facing tools often collapse under unclear ownership, lack of user empathy, and no measurable success criteria” (Gartner, 2024).

So how do you build a platform your developers will actually want to use?

The Answer: Treat Your Internal Platform Like a Product

This post explores lessons from top-performing platform teams at companies like Shopify, Netflix, Spotify, and Wealthsimple. We’ll cover:

• Why treating your IDP as a product—not just a project—is critical.

• How to create tight feedback loops with developers.

• The platform metrics that matter (beyond uptime).

• Real-world case studies and actionable implementation guides.

We’ll also link to related CrashBytes posts, such as Optimizing CI/CD Pipelines for Global Teams and Developer Experience Metrics: What Engineering Leaders Need to Track.

The Shift: From Infrastructure Automation to Developer Product

What is an Internal Developer Platform?

An Internal Developer Platform (IDP) provides developers with self-service access to tools, workflows, and environments. At its best, it removes cognitive load from engineering teams and accelerates delivery.

Typical IDP features include:

• Self-Service Infrastructure: Provision Kubernetes clusters, databases, or queues without ticketing ops.

• Golden Paths: Predefined deployment pipelines, security policies, and standardized templates.

• CI/CD Integrations: Seamless build, test, and deploy workflows.

• Environment Management: On-demand staging environments with parity to production.

But tooling alone doesn’t create value.

As Camille Fournier, author of The Manager’s Path, points out:

“Internal platforms aren’t valuable unless developers actually want to use them. Adoption is the outcome, not the starting point.”

Lesson 1: Treat Your Internal Platform as a Product

Platforms Are Products, Not Projects

High-performing platform teams act like product teams.

At Spotify, the Backstage platform team follows a product mindset. They prioritize user research, roadmap iteration, and regular feedback cycles—not just technical delivery.

This requires:

Create a Dedicated Platform Product Owner

Companies like Netflix and Wealthsimple assign Platform Product Owners (PPOs) who:

• Conduct user interviews.

• Prioritize features based on developer pain points.

• Define KPIs tied to business outcomes.

Example: Netflix

Netflix’s engineering blog describes their IDP as “a product with its own backlog, dedicated PM, and UX research.” They run quarterly developer satisfaction surveys to adjust priorities (Netflix Tech Blog).

Lesson 2: Build Tight Developer Feedback Loops

Why Developer Feedback Is Non-Negotiable

According to McKinsey, “teams that continuously gather and implement developer feedback deliver platform features 30% faster” (McKinsey, 2023).

Feedback prevents:

• Overengineering solutions nobody needs.

• Building tools that don’t fit real workflows.

• Losing trust with developers.

Methods for Collecting Feedback

1. Embedded Platform Advocates

Shopify embeds platform engineers within feature teams. This creates natural, trust-based channels for feedback.

2. Open Office Hours

At Wealthsimple, the platform team hosts weekly “Ask Me Anything” (AMA) sessions via Slack and Zoom.

3. Developer Journey Mapping

Map out common developer workflows. Identify friction points and gather qualitative input.

Template: Developer Journey Map

Lesson 3: Define Success Metrics That Actually Matter

Avoid Vanity Metrics

Traditional platform teams often measure:

• System uptime

• Number of deployments

• Tickets closed

These are operations metrics, not product success indicators.

Developer-Centric Platform Metrics

DORA Metrics Extension for Platforms

Lesson 4: Build for Adoption, Not Control

Make Golden Paths Optional (but Desirable)

At Spotify, golden paths are recommended, not enforced. This builds trust while encouraging consistency.

Example: Spotify Backstage

Backstage offers templates for microservice creation but allows teams to customize. This balance between standardization and autonomy is critical for adoption.

Explore Backstage

Lesson 5: Show Developers the “What’s In It For Me”

The Adoption Equation

Developers adopt platforms when:

Perceived Value > Perceived Cost

How to Increase Perceived Value:

• Save developers time (faster deployments, fewer meetings).

• Reduce context switching (single pane of glass for dev workflows).

• Improve developer happiness (less toil).

How to Reduce Perceived Cost:

• Lower cognitive load (no YAML unless necessary).

• Provide great docs and examples.

• Offer excellent support (Slack channels, docs, office hours).

Case Study: Wealthsimple’s Platform-as-Product Model

Company: Wealthsimple Platform: Kubernetes-based IDP Approach: Treat platform as a product

What They Did:

• Appointed a Platform Product Manager.

• Held weekly developer feedback sessions.

• Built a self-service portal with templates for common tasks.

• Measured time-to-onboard and developer satisfaction quarterly.

The Result:

• Reduced service deployment setup from 3 weeks to 2 days.

• Achieved a +52 Developer NPS, up from +5 before the changes.

• Increased platform adoption from 20% to 90% across teams.

Source: Wealthsimple Engineering Blog

Real-World Example: Amazon’s Internal Platform Culture

At Amazon, internal platform teams follow a Working Backwards approach:

1. Write a press release for the platform before building it.

2. Focus on customer obsession—in this case, internal developers.

3. Use metrics-driven prioritization, tying platform features to customer impact.

This approach led to the creation of services like:

• Apollo: Amazon’s deployment platform, used by over 100,000 deployments daily.

• Brazil: Amazon’s internal service-oriented architecture management system.

Read: How Amazon Builds Platforms

Implementation Guide: Building Your Developer-Centric Platform

Step 1: Set Up a Platform Product Team

• Roles Needed:

  • Platform Engineering Lead

  • Platform Product Manager

  • Developer Advocate or UX Researcher

Step 2: Conduct Developer Research

Use these questions to guide interviews:

• What’s the hardest part of your daily workflow?

• Where do you feel blocked?

• What tools do you avoid—and why?

• How do you prefer to get help? (Slack, docs, office hours?)

Step 3: Prioritize Features by Impact

Use Impact vs Effort mapping to rank initiatives.

Step 4: Measure Success Continuously

Set up quarterly reviews using:

• Developer NPS surveys

• Time-to-onboard measurements

• Cognitive load assessments

Common Pitfalls (and How to Avoid Them)

The Future of Internal Developer Platforms

Emerging Trends:

• Platform Orchestration Tools: Tools like Humanitec are automating IDP assembly.

• Developer Experience (DevEx) Teams: More orgs are formalizing DevEx ownership.

• Platform Engineering Guilds: Cross-company collaborations like the Platform Engineering Community.

Beyond the Tooling

Ultimately, building an IDP is about people, not just tech.

As Charity Majors, CTO of Honeycomb, says:

“Tools don’t create high-performing teams. People do. But tools can remove the roadblocks that frustrate people.”

Conclusion: Build for Trust, Iterate for Value

If you want your Internal Developer Platform to succeed:

• Treat it like a product.

• Listen to your developers—continuously.

• Measure what matters, not just uptime.

• Prioritize adoption over control.

By following these lessons from high-performing teams, you’ll create a platform that developers actually love to use—not one they’re forced to use.

Crosslinks & Backlinks

• Optimizing CI/CD Pipelines for Global Teams

• Developer Experience Metrics: What Engineering Leaders Need to Track

• Backstage.io by Spotify

• Platform Engineering Community

• AWS Builders Library