Internal developer platforms: what to build first

Build the golden path for the one journey your developers repeat most, such as spinning up a new service, and make that journey clearly better before you build anything else. Make sure it tells developers what happened, especially when something fails. Then measure speed and stability together, so you know whether the platform is helping delivery. Each of those steps comes from DORA’s guidance on platform engineering.¹

Having a platform is now the norm. In DORA’s 2025 research, a survey of nearly 5,000 technology professionals worldwide,² 90% of organisations reported using an internal developer platform, and 76% had set up dedicated platform teams.¹ So the useful question is no longer whether to have one. It’s whether yours makes delivery better.

What a platform is

DORA describes platform engineering as a sociotechnical discipline: building shared tools, services and “golden paths” that make it easy for development teams to build, test and deploy their applications securely, reliably and in a compliant way.¹ The result is often called an internal developer platform.

The important word is product. DORA says a platform is “best understood as an internal product designed specifically for developers”, not a collection of infrastructure tickets.¹ Its main job is to take complexity off developers’ hands. Rather than every team becoming expert in Kubernetes, cloud networking or security policy, the platform takes that complexity on, behind simple self-service paths.

A golden path, sometimes called a paved road, is the supported way to do a common job: create a service, deploy a change, find out why a release failed. It should be the easiest route, not the only one allowed.

It’s also the natural home for security and compliance work that every team would otherwise repeat, such as keeping the records you’d need to act quickly on the Cyber Resilience Act’s reporting duty.

What a platform isn’t matters as much. It isn’t a platform built without asking developers what they need, a platform team working apart from the people it serves, or a queue of tickets in place of self-service. DORA lists all three as pitfalls.¹

What DORA’s research found

DORA’s 2024 research, a survey of people in technical roles from developers to senior executives, found that internal developer platforms raise developer productivity.³ Its one-page summary puts numbers on the gains, and on the cost:⁴

• Team productivity was 6% higher where the organisation had a dedicated platform team.
• Being able to complete tasks without relying on another team was linked with 5% higher productivity.
• Throughput was 8% lower among people using a platform than among those who weren’t.

The summary calls the overall impact on software delivery mixed. It warns that throughput and stability may both fall, particularly when a platform is mandated for the entire application lifecycle.⁴

DORA’s research also links platform quality to what organisations get from AI. Where platform quality is high, the effect of AI adoption on organisational performance is strong and positive. Where it’s low, the effect is negligible.¹ DORA’s reasoning is that individual gains in coding speed are often lost to bottlenecks in testing, security reviews and complex deployments, which a good platform helps reduce. We looked at the same pattern in whether AI coding assistants make teams faster.

DORA describes a good platform as the distribution and governance layer for AI.¹ If your teams are starting to connect AI agents to internal tools and data, a supported way to do it, with its limits built in, is a golden path like any other.

Those numbers are easy to read as a simple case for platforms. They’re more useful as a warning: a platform can make developers more productive and still slow the flow of changes to production.

Getting a platform started is the easy part: a portal, some templates, a pipeline every team is told to use. Making one journey clearly better, without making delivery less stable, is harder, and it’s where DORA’s advice is most specific.

Start with the journey teams repeat most

DORA’s advice is to start with a “minimum viable platform”. It warns against the temptation to build a comprehensive platform all at once, and suggests you “identify the golden path for the most common workflow and build just enough to make that specific journey demonstrably better”.¹

To find that journey, DORA suggests running the platform like a product, with a product manager focused on developer experience. Map the critical journeys developers take, such as spinning up a new service or debugging a production issue, and find where the friction is worst.¹

In practice, that means four decisions before much gets built:

• Pick one journey. Ask teams which job they repeat most and where they wait on someone else, then watch a few people do it. What people report and what they do can differ.
• Measure it as it is. Time the journey end to end today, and count the hand-offs and tickets along the way. Without that baseline, “demonstrably better” has nothing to be measured against.
• Name an owner. One person accountable for the journey, and for whether developers choose it.
• Make it the easiest route, not the only one. DORA warns against a “golden cage” that forces one path on teams whose needs differ, such as data science or mobile.¹ If teams take the path because it’s easier, that’s evidence it works.

Aim for developers finishing the journey on their own. That’s the independence DORA’s 2024 research linked with higher productivity.⁴ A golden path that still needs a ticket to the platform team for its last step hasn’t removed the wait. DORA also advises clear APIs and a way for other teams to contribute, so the platform team doesn’t become the bottleneck.¹

Building one journey at a time follows the same logic as replacing an old system piece by piece rather than in one rewrite: each step is small enough to check before you take the next.

Tell developers what happened

Once developers are on the path, what matters most is knowing what happened. In DORA’s 2025 data, the platform capability most correlated with a positive experience for the developers using it was giving “clear feedback on the outcome of my tasks”.¹

That counts most when something fails. DORA’s guidance is that developers need to understand what’s happening when they use the platform, especially when something fails, and that the platform should give clear, actionable feedback, logs and diagnostics.¹ A platform that hides complexity can also hide the cause of a failure, unless it’s built to explain it.

Here are two messages for the same failed deployment, both written by us to show the difference:

# Says that something failed
Error: pipeline failed (exit code 1)

# Says what happened, and what to do next
Deploy to staging stopped at step 3 of 5: database migration.
Nothing was deployed. The previous version is still running.
Why: migration 0042 ran past the 5-minute limit.
Next: run the migration on its own, or ask #platform-support to raise the limit.
Logs: https://platform.example.com/runs/8812

A useful failure message answers five questions: what stopped, what state things are in now, why, what to do next and where to look. DORA’s guidance stresses making failure cheap and recovery fast,¹ and clear feedback is much of how a developer recovers without opening a ticket.

Measure speed and stability together

DORA has found that platforms can sometimes reduce throughput and change stability if they aren’t carefully managed, which is why it recommends a balanced scorecard.¹ At its centre are DORA’s five software delivery metrics. The first three measure throughput: how many changes move through the system over time. The last two measure instability: how well deployments go.⁵

DORA’s research has repeatedly demonstrated that speed and stability are not tradeoffs.

For most teams the metrics move together, and top performers do well on all five.⁵ For a platform team, that means watching both groups at once. A golden path that speeds up deployment but raises the change fail rate hasn’t made delivery better.

DORA suggests platform teams use the metrics to measure their own performance, and that the platform shows application teams theirs.¹ Measure one application or service at a time: DORA warns that blending the metrics across teams can be problematic, and that setting a metric as a goal makes it more likely teams will game it.⁵

Alongside the delivery metrics, DORA suggests tracking developers’ satisfaction with the platform, whether new teams adopt it and keep using it, and whether developers complete the tasks they come to it for.¹

Having a platform isn’t the milestone anymore. Knowing whether it makes delivery faster and safer, for the teams that use it, is.

What to ask your team

A platform is worth what it changes for the teams that use it. For yours, four answers show where you stand:

• which journey it has made demonstrably better, measured against how it was before
• how the five delivery metrics have moved for teams on the golden path, speed and stability together
• how many new teams take the golden path, and how many are still on it months later
• whether a developer whose task fails can tell what happened without asking the platform team

Then the question that matters: which journey do our developers repeat most, and is it faster and safer on our platform than off it?