Most platform teams know exactly what they should be building: the templates and self-service workflows that let developers go from idea to running service without filing a ticket or hunting down the right person on Slack. They're just not building them. They're keeping the lights on instead.
The idea is well-established. A developer opens a portal, picks a service type, fills in a handful of fields, and the platform handles the rest: repository scaffolded to your standards, GitOps workflows ready, infrastructure provisioned, observability wired in. Pure developer self-service. Some teams call these golden paths. The label matters less than the outcome.
The gap between "we have a portal" and "our templates actually work end-to-end" is wider than most teams expect, though. Here's why.
We built one of these flows end-to-end and showed it to customers and prospects. The demo worked well. It also made very clear how much was hidden underneath the clean portal interface.
A single template, one language, one application type, one data store, required serious engineering effort. Infrastructure automation, GitOps configuration, environment provisioning, observability integration. Every additional service type demands something comparable. You get more efficient over time, but the first few paths are steep, and there's no shortcut through that.
The bigger cost is what comes after launch. Scaffolding a service is a solved problem. Keeping generated services aligned with your platform as it evolves is not. Security policies change. Dependencies update. What "good" looks like shifts. The template that created a service six months ago may not reflect how you want services built today. Maintaining templates is an ongoing capability, not a one-time project.
And your templates are yours. Your service types, your compliance requirements, your infrastructure decisions, your team structures all shape what your paths look like. There is no off-the-shelf template that works across organizations. That's what makes them valuable, and it's what makes them expensive to build and sustain.
Platform teams are typically stretched across too many layers at once: managing Kubernetes clusters, maintaining portal infrastructure, handling reliability and security concerns, and then trying to build and maintain high-quality templates on top of all of that.
The result is predictable. The highest-value work, the templates and workflows that only your team can build for your organization, gets squeezed out by lower-level work that isn't unique to you at all.
Templates only stay valuable while they stay current. When they drift from your actual standards, trust drops. When trust drops, developers route around them. At that point you don't have a platform, you have a set of optional tools that add process without adding value.
The teams making real progress on developer self-service aren't working harder across all those layers. They're making a deliberate choice about which ones to own.
Your templates, your developer workflows, your organizational standards: those are yours to build. The Kubernetes operations, the portal framework, the infrastructure plumbing: that work doesn't have to live with your team.
When platform engineers stop spending cycles on problems that have already been solved elsewhere, they get the one thing the template work actually requires: sustained focus. The ability to iterate on paths, keep them current, measure whether they're being adopted because they're genuinely better, and go deeper on the workflows that change how fast your teams ship.
That shift, from keeping foundations running to building the layer only you can build, is where the leverage actually is.
There's a direction worth watching that changes the calculus further. Agentic AI tooling is starting to reduce the real effort of creating and maintaining templates: scaffolding paths from organisational context, propagating standards changes across generated services, flagging drift before it erodes trust. The vision is a platform engineer who authors intent rather than hand-builds every path.
For platform teams already asking "how do we maintain this as we grow," it's the right question to be sitting with now.
The work is too context-specific, too ongoing, and too important to happen in the margins. If your platform team is caught between keeping foundations running and building something better, we'd be glad to think through it with you.