Building an internal platform is only half the job. The real return comes when developers trust it, want to use it, and help make it better.
Platform engineering has become a strategic investment for many engineering organisations. Teams are building internal developer platforms, standardising CI/CD pipelines, creating self-service infrastructure, and providing tools designed to make developers more productive.
The promise is compelling: reduce cognitive load, eliminate duplicated effort, improve consistency, strengthen security, and let product teams focus on delivering business value rather than managing infrastructure.
Organisations invest significant time, money, and engineering talent to make this happen.
And yet, something often gets lost along the way.
The platform gets delivered. The migration happens. The documentation is published. The new workflow becomes the official standard.
But developers are still frustrated.
They encounter confusing errors, unreliable workflows, missing capabilities, and problems that require them to ask another team for help. They learn which workarounds are necessary, which parts of the platform they can trust, and which problems are easier to avoid altogether.
Eventually, they comply with the new way of working. But compliance is not enthusiasm, and adoption is not necessarily success.
The organisation has invested in a platform, but it has not fully realised the return on that investment.
Why does this happen, and what can we do about it?
1. The last 10% matters more than you think
Platform teams are often very good at delivering the big things.
They build the infrastructure, establish common patterns, automate the happy path, integrate the necessary services, and provide a consistent interface for developers.
These are difficult and valuable achievements.
The problem is what happens next.
The platform works, but not always reliably. The common workflow is straightforward, but the unusual case is painful. An error occurs, but the message doesn't explain what went wrong or how to fix it. A pipeline fails, and determining whether the problem is in the application, the configuration, or the platform itself becomes an investigation.
None of these problems necessarily looks significant in isolation.
Collectively, however, they define the developer experience.
Consider two internal platforms that provide exactly the same capabilities.
With the first, a developer can complete a task in minutes when everything works, but diagnosing a failure takes hours and requires support from the platform team.
With the second, the task takes the same amount of time when everything works, but failures are clearly explained, diagnostics are available, and the developer can resolve most problems independently.
Technically, both platforms may be equivalent. In practice, they deliver very different levels of value.
This is the last-mile problem in platform engineering.
We invest heavily in capabilities, but sometimes underestimate the effort required to make those capabilities dependable, intuitive, and pleasant to use.
The last 10% might be the least glamorous part of the roadmap. It is also where much of the difference between a usable platform and a genuinely valuable one is created.
2. Developers don't fall in love with roadmaps. They fall in love with experiences.
Imagine that your organisation announces a major investment in a new developer platform.
There is an ambitious roadmap, a dedicated team, a polished launch presentation, and a clear strategic rationale.
Developers are encouraged to migrate their applications and embrace the new tooling.
Initially, there is curiosity. People try the platform, explore its capabilities, and perhaps even get excited about what it could eventually become.
Then they start using it for real work.
They encounter friction. Some workflows are slower than expected. Documentation doesn't cover their situation. Failures are difficult to diagnose. Requests for improvements disappear into a queue.
Over time, the initial excitement fades.
Developers stop exploring new capabilities. They stop reporting minor bugs because the process feels disproportionate to the problem. They stop suggesting improvements because they don't expect much to happen. They learn the minimum required to get their jobs done.
The platform becomes something they have to use rather than something they want to use.
This distinction matters.
When developers genuinely value a tool, they become its advocates. They recommend it to colleagues, experiment with new features, report problems, suggest improvements, and invest time in helping it evolve.
When they merely tolerate it, they do the minimum required.
This creates a vicious cycle:
- The platform has usability problems.
- Developers become reluctant to engage with it.
- The platform team receives less useful feedback and fewer contributions.
- Problems remain unresolved or are discovered later than they otherwise would be.
- The developer experience deteriorates, reinforcing the original reluctance.
The result is a platform that may look successful on a dashboard but is not reaching its full potential.
You cannot mandate genuine enthusiasm. You have to earn it through the experience you deliver.
3. The hidden cost of making developers dependent on the platform team
A successful internal platform should increase developer autonomy.
Developers should be able to provision resources, deploy applications, understand failures, and solve common problems without having to coordinate with a central team for every step.
Yet many platform implementations inadvertently create new dependencies.
A pipeline fails, so the developer raises a ticket.
A configuration behaves unexpectedly, so they contact the platform team.
A feature is missing, so they submit a request and wait.
A bug needs fixing, but the relevant code is owned by another team, and the only available path is through its backlog.
The platform may have automated many manual tasks, but the organisation has replaced one kind of dependency with another.
This is particularly costly because platform teams are usually responsible for shared capabilities used by many product teams. Every unnecessary support interaction consumes capacity that could otherwise go towards improving the platform itself.
There is also an opportunity cost for the consuming teams. Developers spend time waiting, investigating workarounds, explaining issues, and coordinating with people who understand the platform better than they do.
A platform that requires constant human intervention to operate has not fully delivered on the promise of self-service.
Of course, some interactions with platform specialists are necessary. Complex infrastructure, security-sensitive changes, and architectural decisions often need expert involvement.
The goal isn't to eliminate the platform team. It is to eliminate unnecessary dependencies on it.
A good platform enables developers to solve the problems they are equipped to solve, while making it easy to involve specialists when their expertise is genuinely needed.
4. Why can't developers help fix the platform?
Here is a scenario that should be familiar to many engineering teams.
A developer encounters a failure in a shared deployment pipeline. They suspect a defect in the pipeline itself rather than their application.
What happens next?
Perhaps they open a ticket in an IT service management system. They provide logs, explain what they were doing, and wait for someone to investigate.
Another team encounters the same problem. They open another ticket, provide similar information, and wait too.
Eventually, a platform engineer investigates both reports, identifies the underlying defect, implements a fix, and releases an update.
This process might work. But it is unnecessarily expensive if the developers encountering the problem could have collaborated directly with the maintainers.
Now imagine a different workflow.
The developer navigates to the shared platform's source repository and asks an AI coding agent to investigate the failure.
The agent examines the available logs and configuration, helps determine whether the problem originates in the application or the shared platform, and searches existing issues for similar reports.
If an issue already exists, the developer can contribute evidence and confirm that another application is affected. If no issue exists, the agent helps prepare a new one with useful diagnostic information.
Other teams can discover the issue, contribute their findings, and discuss a solution in the same place.
Perhaps a developer from one of those teams identifies the root cause and proposes a fix through a pull request. The maintainers review it, run the necessary tests, and merge it.
The platform team still owns the platform. It still defines standards, reviews changes, and ensures quality.
But it is no longer the only team capable of improving it.
This is the difference between a support model and a contribution model.
In the first, consumers report problems and maintainers solve them.
In the second, consumers and maintainers collaborate to solve problems together.
That is the foundation of an inner-source culture: applying the collaborative practices of open source within an organisation.
5. AI makes this opportunity much more compelling
The contribution model described above isn't entirely new. Inner-source practices have existed for years.
What is changing is the cost of participation.
Historically, contributing to a shared platform could require considerable effort. A developer needed to understand the repository structure, locate the relevant code, reproduce the problem, navigate contribution guidelines, and prepare a useful issue or pull request.
For someone unfamiliar with the platform, that initial investment could be substantial.
AI coding agents can reduce this barrier.
With appropriate repository access and tooling, an agent can help developers:
- Understand unfamiliar platform code.
- Diagnose failures using logs, configuration, and source code.
- Determine whether an issue is likely to originate in the application or the shared platform.
- Search existing issues and documentation for known problems.
- Produce well-structured bug reports with relevant diagnostic evidence.
- Identify potential fixes and prepare draft pull requests.
- Write or improve tests to reproduce a defect.
These capabilities do not guarantee correct diagnoses or safe changes. Agents can be wrong, miss context, or propose fixes that introduce regressions. Human review, automated testing, access controls, and appropriate security boundaries remain essential.
But the potential is significant.
AI can make it easier for developers to cross the boundary between consuming a platform and contributing to it.
This is particularly valuable in large organisations, where the people most affected by a platform defect may be the people best positioned to reproduce it, understand its impact, or even propose a solution.
The platform team doesn't have to become less important. Its expertise can be applied where it creates the most value: architectural direction, quality, reliability, difficult problems, and enabling contributions from across the organisation.
6. Your tooling choices can either enable or undermine collaboration
Culture matters, but culture doesn't exist independently of the systems people use every day.
If source code lives in one place, issues in another, documentation in a third, and technical discussions in a fourth, contributing to a shared platform becomes harder than it needs to be.
Developers must navigate multiple systems, maintain separate accounts or permissions, repeat information, and reconstruct context that is scattered across different locations.
The organisation may have all the necessary tools. Yet the overall workflow remains fragmented.
This is especially problematic when the official process encourages developers to report a problem through a ticketing system but offers no straightforward path to investigate the underlying code or contribute a fix.
A more collaborative approach is to bring technical work closer to the source.
For code-centric platform engineering, a repository-centred workflow can provide a natural home for:
- Source code and version history.
- Issues, defects, and feature requests.
- Technical documentation and contribution guidelines.
- Pull requests, reviews, and design discussions.
- Automated testing and continuous integration.
GitHub is one example of a platform that supports this model. Other tools can support similar workflows. The specific product is less important than the principle.
The place where a problem is reported should also be a place where people can understand it, discuss it, and contribute to fixing it.
There may still be good reasons to retain separate systems for service management, compliance, incident response, or formal approvals. The objective isn't to force every organisational process into a single tool. It's to avoid unnecessary separation between the technical artefacts and the people trying to improve them.
7. Platform engineering needs a product mindset
Perhaps the most fundamental change is to how we define success.
Many engineering initiatives are organised around delivery milestones: build the platform, release the capability, migrate the applications, and declare the project complete.
But internal platforms aren't finished when they launch.
They are products with users, competitors, changing requirements, operational costs, and an ongoing need for improvement.
Those users happen to be colleagues rather than external customers. That doesn't make their experience any less important.
A product mindset means treating feedback as a continuous input, prioritising usability alongside capability, and measuring whether the platform actually helps developers achieve their goals.
It also means accepting that the best feature to build next may not be a new capability.
It might be fixing an unreliable workflow. Improving an error message. Making a common failure self-diagnosable. Reducing the time required to onboard an application. Removing a manual approval that no longer adds value.
These improvements may be less impressive in a launch announcement, but they can have a substantial impact across hundreds or thousands of developers.
The platform team should therefore ask not just, "What should we build next?" but also, "What prevents developers from getting value from what we have already built?"
That second question is often where the most immediate returns can be found.
8. Measure value, not just activity
If we want platform investments to deliver better returns, we need to measure outcomes rather than relying exclusively on delivery metrics.
Counting onboarded applications, available features, pipeline executions, or registered users can tell us something about reach and activity. They don't necessarily tell us whether developers are better off.
A more useful measurement framework might include:
Developer experience
- How satisfied are developers with the platform?
- How often do they encounter friction in common workflows?
- Do they trust the platform for critical work?
Reliability and productivity
- How frequently do platform-related failures occur?
- How long does it take to diagnose and resolve them?
- How much developer time is spent waiting for support or working around limitations?
Autonomy and self-service
- What proportion of common problems can developers resolve independently?
- How often do they need human intervention?
- How long does it take to onboard an application or complete a routine task?
Contribution and continuous improvement
- How easy is it to report a defect with enough information to act on it?
- Can consuming teams contribute changes?
- How long does it take to review and release a valid contribution?
- Are developers actively helping improve the platform?
These measures should be interpreted together rather than turned into isolated targets. For example, a high number of pull requests isn't necessarily evidence of success if those contributions are low quality or reflect a platform full of defects.
The aim is to understand whether the platform is reducing friction, enabling autonomy, and delivering value to the teams that depend on it.
9. What should organisations do differently?
The answer isn't to abandon platform engineering or to assume that every problem can be solved by changing tools.
The opportunity is to improve how platforms are built, operated, and evolved.
Here are five practical starting points.
1. Prioritise the last mile.
Reserve meaningful capacity for reliability, usability, diagnostics, documentation, and the removal of recurring friction. Don't allow new feature development to consume the entire roadmap.
2. Make common failures self-diagnosable.
Invest in actionable error messages, structured logs, troubleshooting guidance, and diagnostic tooling. Developers should be able to understand what failed and what to do next.
3. Make contribution a first-class workflow.
Document how to report issues, propose changes, run tests, and contribute fixes. Make it possible for consuming teams to participate without needing to become platform experts first.
4. Use AI to lower the cost of participation.
Where appropriate, provide agents with access to the relevant source code, documentation, issues, and diagnostic tools. Let them help with investigation and contribution, while retaining human oversight and appropriate safeguards.
5. Measure whether developers actually benefit.
Gather feedback, track reliability and resolution times, and examine the friction developers encounter in real workflows. Use that evidence to determine what to improve next.
None of these requires a massive transformation programme to get started. A team can begin with one frequently failing workflow, one repository, and a clear commitment to making problems easier to diagnose and fix.
The important thing is to close the feedback loop.
Conclusion: The return on platform engineering is earned after delivery
Platform engineering offers enormous potential. Shared infrastructure, standardised workflows, self-service capabilities, and reusable tooling can make engineering organisations more productive, consistent, and secure.
But building these capabilities is only part of the job.
The return on that investment depends on what happens when developers use the platform every day: whether it works reliably, whether problems are easy to solve, whether feedback leads to improvements, and whether the people who depend on it can help make it better.
A platform that developers are required to use can achieve broad adoption without earning their trust.
A platform that developers trust can achieve something much more valuable: voluntary engagement, advocacy, and continuous improvement.
That is why the last 10% matters. It is why self-service must mean more than automating the happy path. And it is why collaboration should be built into the platform's operating model rather than treated as an administrative process around it.
The next evolution of platform engineering should not simply be about building more platforms or adding more capabilities.
It should be about making existing platforms better to use, easier to understand, and easier to improve.
The real measure of a platform isn't how much engineering went into building it. It's how much friction it removes for everyone who depends on it — and how effectively those people can help it evolve.
That is how platform investments become lasting engineering value.
