An internal developer platform succeeds when developers choose it because it makes delivering software easier, not simply because the organisation has told them to use it.
Building the technology is only the beginning. The harder task is making the platform useful enough to become the normal way of working. That requires product ownership, a deliberately narrow starting point, valuable golden paths, genuine self-service, embedded controls and measures tied to software delivery, not platform activity.
What is an internal developer platform?
An internal developer platform (IDP) is a shared set of tools, automated workflows, templates and services that gives development teams self-service access to common engineering capabilities. Instead of each team building and maintaining its own pipelines and controls, a platform team provides reusable capabilities that can be accessed on demand.
The important word is platform, not portal. A developer portal may provide the front-end interface through which teams discover and access services, but it is only one part of an IDP. The underlying automation, workflows and controls are what make self-service possible.
If you are still considering where an IDP fits, begin with our guide to Platform Engineering vs DevOps. This article takes the next step – how to make platform engineering work in practice.
Why internal developer platforms fail after launch
Internal developer platforms rarely fail because an organisation lacks technology. More often, the platform becomes an internal technology programme rather than a product developers actually want to use.
Four patterns account for much of the problem:
- The platform solves the platform team’s problems, not developers’ problems. Standardisation takes priority over removing the friction developers encounter every day.
- Too much is built before its value is proven. Features accumulate before anyone establishes what developers need or will use.
- Golden paths become compulsory routes. Teams are forced to follow processes that can be slower than completing the work themselves.
- Activity is mistaken for value. Logins, users and templates increase, but software delivery is not demonstrably faster, safer or more reliable.
DORA’s 2024 research highlights both the potential value and the potential trade-offs. It found that internal platforms can improve individual productivity, team performance and organisational performance, but may also reduce change stability and throughput. The findings reinforce the importance of user-centred design and developer independence when implementing an IDP.
The objective is not to maximise platform adoption. It is to create enough value that adoption becomes the rational choice.
1. Treat the IDP as a product, not a project
A project has a delivery date. A product has users, an owner, a roadmap, continuous feedback and an ongoing reason to exist.
DORA describes this as a platform-as-product mindset; understand what internal developers need and treat developer independence as a core design principle, not an afterthought.
In practice, the platform backlog should be driven by where developers lose time, what teams repeatedly rebuild and which processes people routinely work around, not by the next portal feature.
The same discipline applies after launch. Monitor what teams use, where they abandon workflows and what continues to frustrate them. An occasional exception may reflect a genuinely different requirement. Repeatedly bypassed workflows are a signal that the platform is not meeting developers’ needs.
Observe friction. Prioritise. Improve. Measure. Learn.
A useful platform roadmap should look more like a list of developer problems being removed than a catalogue of technical capabilities being delivered.
2. Start with the smallest valuable golden path
Trying to build a complete IDP from day one is one of the fastest ways to create an expensive internal system that nobody asked for. Start with the smallest intervention capable of proving value.
AWS recommends identifying where developers experience cognitive load, reviewing the existing tools and processes and beginning with a single golden path.
Team Topologies describes a similar principle as the Thinnest Viable Platform; the smallest amount of platform needed to accelerate delivery, rather than a large platform built for its own sake.
The first golden path should meet three tests:
- The journey happens frequently
- It creates meaningful friction
- Improving it would produce a measurable outcome
That could mean provisioning an environment, creating a service or deploying an application. Solve one valuable problem, establish whether the solution works and use what you learn to determine where the platform should expand next.
3. Make the golden path easier than going around it
A golden path is a supported route through a common engineering task. It brings together sensible defaults, automation and standards so that developers do not have to rediscover the same answers every time.
A golden path succeeds when developers choose it because it removes work. When it creates more work than the alternative, it becomes another layer of governance.
AWS recommends keeping platform capabilities optional while the IDP matures. Teams should be able to adopt individual capabilities rather than being forced into wholesale adoption. Golden paths can then embed testing, security scanning, policy-as-code and deployment standards within the routes developers choose to use.
Standardisation creates value when teams repeatedly solve the same problem. It creates friction when genuinely different workloads are forced through the same process.
A mature platform therefore needs managed exceptions. Teams should be able to deviate where there is a legitimate engineering reason, while the platform remains the easiest and best-supported option for the usual case.
The goal is not to remove choice. It is to make the sensible choice the easiest one.
4. Build self-service around developer journeys
Platform teams often begin with architecture. Developers think in journeys – somewhere to run a service, a way to move a change into production and a way to know whether the service is working properly.
Design the platform around those journeys.
Self-service creates value when it removes dependency on another team without requiring developers to understand the platform’s internal structure. AWS recommends hiding unnecessary complexity behind straightforward interfaces, whether APIs, command-line tools or graphical interfaces.
This is also why buying or building a developer portal does not automatically give an organisation an IDP. The interface only creates value when meaningful automated capabilities exist behind it.
A beautifully designed front door to the same manual ticket queue is still a ticket queue.
5. Put controls inside the path, not around it
In regulated organisations, platform engineering becomes more valuable when it makes the approved route easier to follow rather than adding another governance layer.
Security, testing and operational controls can be built directly into golden paths. These might include automated security scanning, policy-as-code, approved infrastructure templates and traceable deployments that generate evidence as the work takes place.
AWS recommends embedding security scanning and policy-as-code within golden paths so that developers receive feedback during delivery rather than encountering security as a separate downstream process.
For financial services organisations, this approach can help teams apply and evidence technical controls that support FCA operational resilience requirements and PRA operational resilience expectations.
For government organisations, it can help teams incorporate controls aligned with the NCSC’s secure design principles and the GOV.UK Service Standard into normal delivery workflows.
Traditional governance often asks teams to demonstrate after the event that they followed the correct process. A well-designed platform makes the compliant route the default and generates evidence as part of delivery.
6. Measure delivery outcomes, not platform activity
A platform can have thousands of logins and still be failing. Usage shows that people interacted with it; it does not prove that software delivery became faster, safer or more reliable.
DORA recommends measuring platform experience and delivery outcomes together. This includes developer satisfaction, adoption and retention, task success and software delivery performance. Its core delivery measures cover change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate.
A practical scorecard might look like this:
| Activity measure | Better question | Outcome measure |
|---|---|---|
| Portal logins | Are teams delivering changes faster? | Change lead time |
| Number of templates | Can teams complete common tasks more easily? | Task completion time |
| Number of platform users | Is onboarding becoming easier? | Time to first production deployment |
| Tickets closed | Has self-service reduced dependency on other teams? | Platform-related ticket volume |
| Deployment volume alone | Are teams releasing more frequently without increasing failure? | Deployment frequency and change fail rate |
| Tool adoption | Do developers find the platform useful enough to keep using? | Developer satisfaction and retention |
| Platform uptime alone | Is the wider delivery system becoming more reliable? | Recovery time and service reliability |
John Lewis Partnership provides a useful UK example. Its platform team found that adoption alone did not show whether the platform was creating meaningful value. Its approach developed from measuring service-creation and onboarding lead times to examining DORA measures, technical health and developer feedback.
The platform should ultimately be judged by what improves outside the platform.
When the IDP is not the real problem
An internal developer platform may not be the problem you need to solve. If deployments are unreliable, test automation is weak, ownership is unclear or releases depend on manual intervention, wrapping those processes in an IDP will not fix them. It may simply make weak practices easier to repeat.
This is central to Catapult CX’s wider DevOps approach. Identify where delivery slows, breaks or waits before deciding what intervention is required.
Before investing further, ask:
- Is repeated platform work really constraining delivery, or is the pipeline itself unreliable?
- Is self-service missing, or are responsibilities and ownership unclear?
- Do we need a platform intervention, or do the underlying DevOps practices need to be strengthened first?
Where the answer is unclear, Catapult CX’s DevOps Health Check & Uplift identifies the underlying delivery constraints before an organisation commits to wider tooling or transformation investment.
Do not productise a broken process
Enterprise scale depends on consistency, not centralisation
Large engineering organisations need consistency, but that does not mean every decision should sit with a central team.
Our work with a global bank demonstrates the scale of this challenge. This was a DevOps transformation rather than an internal developer platform implementation, but it depended on many of the same principles; reusable practices, distributed ownership, consistent controls and the removal of delivery bottlenecks across the organisation.
Operating across 71 locations with more than 45,000 IT staff, the bank established over 2,000 cross-functional DevOps teams. The transformation onboarded 10,000 users in 12 weeks, reduced cycle time from 90 days to 15 and saved one business unit more than 4,500 engineering hours each year.
At this scale, repeatedly rebuilding the same capabilities across different teams no longer makes sense. An IDP can provide consistency by standardising what teams should not have to solve for themselves, while leaving genuinely team-specific decisions with the people best placed to make them.
Making an internal developer platform stick
A successful internal developer platform should eventually become almost unremarkable – a set of supported paths that removes complexity without requiring developers to think about the machinery underneath.
Getting there starts with the delivery problem, not the technology. Catapult CX helps organisations identify where software delivery is slowing down, determine whether platform engineering is the right response and define the smallest intervention capable of producing measurable value. This can include strengthening DevOps and CI/CD foundations, designing golden paths, embedding security and governance controls and establishing how success will be measured.
If you are considering an internal developer platform, or already have one that is not delivering the expected value, our DevOps Health Check & Uplift can help identify whether the constraint lies in the platform, the delivery pipelines or the wider operating model.
Platform engineering works when the platform removes friction from good engineering practices. It does not rescue bad ones.
FAQs about internal developer platforms
What is an internal developer platform?
An internal developer platform (IDP) is a shared set of tools, automated workflows, templates and services that gives development teams self-service access to common engineering capabilities. It allows teams to use proven pipelines, infrastructure and controls without having to build and maintain them independently.
What is platform engineering?
Platform engineering is the practice of designing and managing reusable tools, workflows and services that make software delivery easier for development teams. An internal developer platform is one way of providing those capabilities through a consistent, self-service experience.
What is a golden path in platform engineering?
A golden path is a supported, reusable route through a common development or delivery task. It combines automation, standards and sensible defaults to make activities such as creating a service, provisioning an environment or deploying software easier and more consistent.
Should golden paths be mandatory?
Not in every situation. A golden path should be the easiest and best-supported route for a common task, but teams may need to deviate where there is a legitimate technical or operational reason. Requiring every workload to follow the same route can create friction and encourage teams to work around the platform.
What is the difference between an internal developer platform and a developer portal?
An IDP includes the tools, automation, workflows and controls that provide self-service engineering capabilities. A developer portal is the interface through which teams discover and access those capabilities. It can form part of an IDP, but it is not the whole platform.
How do you measure the success of an internal developer platform?
Measure platform experience and software delivery outcomes together. Relevant measures include developer satisfaction, adoption, retention, task completion and onboarding time, alongside change lead time, deployment frequency, failed deployment recovery time and change fail rate. Usage data alone does not demonstrate that the platform is creating value.
Why do internal developer platforms fail?
Internal developer platforms often fail because too much is built before demand is established, the platform is designed around tools rather than developer needs, unsuitable golden paths are imposed on teams or success is measured through activity rather than improvements in software delivery.
Does every organisation need an internal developer platform?
No. An IDP is most useful when multiple development teams repeatedly need the same engineering capabilities and are losing time to manual provisioning, duplicated tooling, inconsistent pipelines or fragmented controls. Smaller organisations or those with unreliable delivery foundations may need to address their underlying DevOps practices first.
How should an organisation start building an internal developer platform?
Start with one frequent, high-friction developer journey where improvement would create measurable value. Build the smallest useful golden path, test it with developers and expand only after the initial capability has proved its value.
Can an internal developer platform support security and compliance?
Yes. Security scanning, policy-as-code, approved infrastructure templates, testing and evidence generation can be embedded directly into golden paths. This helps teams apply controls consistently and receive feedback during delivery rather than encountering security or compliance as a separate process at the end.
