Platform engineering - Xebia: Why internal engineering precedes external excellence

The hidden backbone 

Internal platforms are more than just developer portals – they are the invisible plumbing of high-performing engineering organisations, helping reduce cognitive overload and provide developers with the self-service capabilities they need to unlock delivery at scale. In other words, not only do internal platforms enable engineering velocity, they also double as talent-retention tools by creating an environment where developers can thrive.

When companies neglect internal processes, it can demoralise teams and hinder innovation. That’s because, as software systems continue to get more complex, developers simply won’t have the necessary tools to match the speed, quality and resilience that today’s market demands. Meaning, a company’s first platform customer should be their own development team.

Developer freedom vs. discipline

Gartner found that organisations with high-quality internal developer platforms are 31% more likely to improve delivery flow and 89% of software engineering leaders are actively taking steps to improve developer experience (DevEx). DevEx has become a popular qualitative tool for measuring engineer output and recent research from GitHub shows that better DevEx leads to higher developer productivity.

However, while it’s important to support developers, that doesn’t mean submitting to their every desire. For example, while developers often crave the freedom to choose their own tools, define their own infrastructure and customise workflows, with freedom comes fragmentation. Internal platforms help align autonomy with accountability, ensuring that teams do what’s best for the company without getting sidetracked by too many possibilities. Striking this balance is akin to playing with LEGO® instead of Play-Doh® – developers need boundaries and creativity within constraints produces scalable, maintainable systems.

Internal platforms are an excellent way of enforcing guardrails like pre-configured deployment templates and security policies and they can help guide teams toward best practices. This might reduce flexibility in some areas, but it increases overall delivery quality, speed and resilience. And instead of suppressing creativity, this sort of simplification helps channel it. By embedding governance and operational standards into the platform, developers make fewer high-stakes decisions and spend more time delivering value.

Avoiding bureaucracy, embracing enablement

Madhunapantula: Internal platforms are more than just developer portals – they are the invisible plumbing.

Internal platforms walk a fine line – when poorly executed, they become bottlenecks that create layers of red tape, but when done well, they become accelerators of developer productivity and confidence. The difference is in the methodology and the best platforms are built with developers, not for them. That means taking a “bottom-up” approach that includes engineers in the platform-creation process, assuring that it’s designed to address real-world pain points and provide developers the ability to see (and understand) what the platform is doing on their behalf.

One of the best examples of a well-built internal platform comes from the audio-streaming giant, Spotify. Back in 2018, as Spotify was experiencing massive growth, its software ecosystem became increasingly fragmented, leading to inefficiencies and difficulties in understanding the landscape. 

In response, Spotify created Backstage, an internal platform designed to address the challenges developers faced in onboarding, finding information and understanding service ownership.

What began as a solution to internal fragmentation soon grew into a globally adopted open-source platform for managing the internal developer experience. Backstage unified service discovery, documentation, infrastructure provisioning and observability into a single internal developer portal. But the reason Spotify was successful was because they allowed it to grow through bottom-up adoption, fixing the inside before scaling the outside. The lesson? Use the tools you’re selling – or, put another way, eat your own dog food.

5 key principles

Companies that are planning to build an internal platform (that actually works) are best advised to follow five key principles:

1. Prioritise self-service over ticket queues. Eliminate bottlenecks and empower engineers to move autonomously.
   
2. Secure defaults, not just intentions. Make the secure path the easiest path.
   
3. Provide opinionated (but extendable) templates. Offer strong defaults that teams can tailor.
   
4. Practice developer-centric design. Build interfaces and workflows that developers want to use.
   
5. Avoid “black box” abstractions. Platforms should reduce friction and enable context-aware workflows – if a deployment fails, engineers need logs, metrics and actionable insights.

It’s also imperative to establish KPIs to track the right metrics and ensure the platform is actually improving outcomes, which includes measuring things like: time to onboard a new developer, deployment frequency, change failure rate and internal platform Net Promoter Score. If those metrics aren’t improving, the platform may be solving the wrong problem, or creating new ones.

A new culture

At its core, platform engineering is about culture, because delivery excellence isn’t something that can be layered on – it comes from within. And that starts by addressing how internal engineering teams are being treated. To build scalable, resilient platforms for others, companies need to prioritise their own developers and create the invisible plumbing that will enable their success. Remember, platform maturity isn’t measured by the tools you expose, but by the internal culture you enable.