Internal Developer Platforms: Paved Roads, Not Portals

Q: Why do internal developer platforms fail to get adopted?

Because they are built as portals rather than paved roads, and developers route around anything slower than the workaround they already have. The distinction is the single most useful idea in platform engineering: a portal shows a developer where the work is — a catalogue, a set of links, a form — while a paved road does the work. If your platform’s "create a new service" flow generates a form that files a ticket answered in three days, you have automated the request and none of the fulfilment, and a developer who knows the wait will copy an existing service in an afternoon instead. That is not indiscipline; it is a correct cost assessment. Several related failures compound it. Platforms built for the demo service cover the happy path and break on the long tail, which is most of the real estate. Platforms with a human approval step inside the provisioning critical path are queues regardless of how good the UI is. Platforms with no escape hatch turn the first genuinely unusual team into a permanent detractor, because an abstraction that cannot be opened is a wall. And platform teams that end up processing inbound requests have become the exact bottleneck they were created to remove. Underlying all of it is a category error: treating the platform as a governance surface that teams must pass through, rather than as a product competing for users who are unusually capable of building their own alternative. The platforms that work invert this — they are genuinely the fastest path to production, so fast that going around them is the slower option, with governance riding along inside the road rather than standing in front of it.

Q: What is the difference between a portal and a paved road?

A portal surfaces work; a paved road removes it. A portal is typically a web interface with a service catalogue, links to documentation, dashboards aggregating information from other systems, and forms for requesting things. It improves discoverability, which is genuinely useful, but a developer who uses it still has to do all the underlying work — or wait for someone else to. A paved road is an opinionated, fully-automated route to a working outcome: you choose a template and you get a repository with CI configured, a deployment pipeline, observability wired in (structured logging, traces, dashboards), secrets and IAM provisioned, network policy applied, and compliance controls already satisfied — with the service running in production at the end. The developer did not file anything or wait for anyone. The concrete test that distinguishes them is one number: time from "I need a new service" to "it is running in production with logging, metrics, alerts, CI, and secrets wired up." If that is measured in minutes, you have a paved road. If it is measured in days, you have a portal with good branding, and your adoption number will reflect that. This is also why installing a developer-portal framework and stopping is such a common failure: the catalogue and template layer is real work and genuinely useful, but the provisioning, pipeline, observability, and policy layers underneath are where a paved road actually lives. A catalogue is a map. A paved road is the road. Teams need the road, and they will notice immediately if you have given them a very well-designed map of a place with no roads.

Q: What are golden paths and why do they need escape hatches?

A golden path is the opinionated, fully-supported route for the common case — the template that produces a repository, CI, deployment, observability, secrets, and compliance in one step. An escape hatch is the supported ability for a team to drop below that abstraction to the underlying primitives when the path does not fit their case. You need both, and the escape hatch is what makes the golden path safe to adopt. The reasoning is about incentives at the moment of first friction. Any opinionated abstraction will eventually meet a team whose requirements it does not cover — an unusual runtime, a compliance constraint, an integration the template never anticipated. If the platform offers no supported way down, that team faces a choice between fighting the abstraction and abandoning the platform entirely, and they will abandon it, becoming vocal detractors whose experience discourages others. If instead they can drop to raw infrastructure-as-code for the one layer that does not fit while continuing to use the layers that do, they stay inside the ecosystem, you keep partial consistency, and the relationship survives. The second-order benefit is that escape hatches are a product-research instrument. Every time a team drops out of the golden path, that is a documented gap. When the same escape recurs across several teams, you have identified the next thing to pave — driven by observed need rather than by what the platform team imagined. So the design principle is "opinionated but not exclusive": strong defaults that make the common case effortless, with a clearly supported, non-punitive route out for the cases that differ, and a feedback loop that turns recurring exits into new paved paths.

Q: Should I mandate that teams use the internal platform?

Not before it delivers value, and if it genuinely is the fastest path you will mostly not need to. The mandate reflex is understandable: adoption has stalled, the platform represents real investment, and policy seems like the lever. It fails with this particular audience for a structural reason — the users are engineers, which means they are unusually capable of finding and building alternatives. Mandate a platform that is slower than the workaround and you get shadow pipelines: a "temporary" direct deployment path that becomes permanent, a legacy route nobody removed, a service provisioned out-of-band and never registered. The result is the platform’s overhead plus none of its consistency, and now the inconsistency is hidden rather than visible. The sequence that works is value first, mandate later and narrowly. Make the platform the genuinely fastest route for the most common case, so that adoption is self-interested rather than compelled. Measure adoption honestly and treat non-adoption as a product signal rather than a compliance problem — interview the teams that did not adopt, because they have the diagnosis and are usually happy to give it. Once the platform is demonstrably the fast path for the majority of cases, a narrow mandate on genuinely high-stakes surfaces (production access to regulated data, for instance) becomes reasonable and mostly uncontroversial, because it is not asking anyone to accept a worse experience. The general principle: prohibition is a weak instrument against capable users, attraction is a strong one, and a mandate applied to an unattractive platform mostly generates well-hidden circumvention.

Q: How do I measure whether my platform is actually working?

Three numbers, and most platform teams track none of them. Adoption rate: what fraction of services actually run through the golden path — not how many teams have accounts, not how many people visited the portal, but how many real production services were created and are operated through the platform. Vanity metrics here are especially seductive because portals generate a lot of easily-measured activity that correlates with nothing. Time to first deploy: for a brand new service, how long from zero to running in production with CI, observability, and secrets in place. This is the paved-road test, it is the number that determines whether developers choose the platform, and it should be relentlessly optimised — measure it for real by having someone actually do it, not by estimating from the happy path. DORA delivery and stability metrics segmented by platform users versus non-users: deploy frequency, lead time for change, change-failure rate, and time to restore, computed separately for teams on the golden path and teams who route around it. This segmentation is the honest test of whether the platform creates leverage or overhead, and it is the one platform teams most avoid running — because if platform users are not measurably faster and more stable than non-users, the platform is not paying for itself and that is important to know. Two supporting signals: the number of escape-hatch exits (which identifies what to pave next), and support-ticket volume directed at the platform team (rising volume means self-service is failing somewhere specific). Together these turn platform investment from a matter of conviction into a matter of evidence, which is also what makes it defensible in a budget conversation.

Q: When is an organisation too small for an internal developer platform?

When the number of services and teams is small enough that three good templates and a well-maintained README deliver most of the benefit — which for many organisations is well past the point where someone first proposes building a platform. Building an IDP is an investment with real ongoing cost: a team to build and operate it, a product surface to maintain, documentation, a support model, and a deprecation policy. That cost is justified when it removes duplicated effort across many teams and services. With a handful of engineers and a few services, there is very little duplication to remove, and the platform becomes an expensive abstraction over a problem you do not yet have — the same premature-abstraction failure as any other, just at the infrastructure layer. The signals that you have crossed into needing one: multiple teams solving the same provisioning and observability problems independently and differently; a growing service count where each new service is created by copying and diverging from an older one; onboarding time for a new service or engineer measured in weeks; and compliance or security requirements that are currently satisfied per-team through manual effort and therefore inconsistently. The signals that you have not: one or two teams, a service count in single digits, and an infrastructure setup a new engineer can understand in a day. What to do in the meantime is not nothing — it is the lightweight version: maintain a small number of genuinely good service templates, keep the deployment path simple and documented, and be deliberate about consistency so that when you do build a platform there is a coherent pattern to encode rather than a decade of divergence to reconcile. That preparation makes the eventual platform dramatically cheaper, and it delivers a meaningful share of the benefit immediately.

Q: Should we build on Backstage or build our own platform?

Adopt an existing developer-portal framework for the catalogue and templating layer — building your own is almost never the right use of an innovation budget — but understand clearly that this solves one layer of the problem, not the problem. Backstage and its commercial derivatives are mature, well-supported solutions to service cataloguing, software templates, and documentation aggregation. Those are real needs, the wheel does not need reinventing, and a team that builds a bespoke catalogue has spent months producing something no better than what they could have installed. So the default should be to adopt. The critical caveat is that a catalogue is not a platform. Installing a portal framework and stopping produces exactly the portal-not-paved-road failure: developers get a nice interface that shows them where the work is, and the work is unchanged. The layers where a paved road actually lives are underneath — automated provisioning of environments, secrets, and databases; a deployment pipeline that works without configuration; observability wired in by default; policy and compliance controls applied automatically. Those are largely specific to your cloud, your compliance posture, and your existing tooling, and they are where the genuine engineering effort belongs. The practical shape most successful platforms take: adopt the portal framework for catalogue and templates, invest your team’s effort in the provisioning and pipeline automation that makes the templates actually produce running services, and integrate the two so that choosing a template in the portal results in a deployed service rather than a checklist. Judge any vendor or framework decision by whether it reduces the time-to-first-deploy number, because that is the metric that determines adoption and everything else is secondary to it.

Q: How should a platform team operate day to day?

As a product team serving internal users, with an interaction mode of self-service rather than collaboration — which in practice means that if the team is spending its days on inbound requests, something has gone structurally wrong. The Team Topologies framing is precise and useful: a platform team exists to reduce the cognitive load of stream-aligned (product) teams, and its interaction mode should be X-as-a-Service, meaning product teams consume the platform without needing to engage the platform team. Collaboration is appropriate occasionally — when paving a genuinely new path with a partner team — but as a steady state it means the platform is not self-service and the platform team has become the bottleneck it was created to remove. Concretely, operating as a product team means: maintaining a roadmap that is visible to internal users and driven by their needs rather than by technical interest; doing actual user research, with the highest-value conversations being with teams that did *not* adopt the platform, because they can tell you exactly what blocked them; treating documentation as a first-class product surface rather than an afterthought, since docs are the primary support channel for a self-service product; having a defined support model with expectations, so requests do not arrive as ad-hoc interruptions; and having a deprecation policy, because platforms accumulate paths and removing them without a policy erodes trust permanently. Two operational habits distinguish the effective teams: they measure adoption, time-to-first-deploy, and DORA metrics split by platform users and treat those numbers as the product KPIs; and they run a standing practice of turning recurring escape-hatch exits into newly paved paths, so the roadmap is driven by observed friction rather than by what the platform team finds interesting to build.

Satyam Kumar

Retour au blog

ai-architecture

Your Internal Platform Is a Ticket Queue With a Logo: Building an IDP Developers Actually Use

By Satyam KumarJuly 27, 202612 min read

platform engineering internal developer platform idp golden paths developer experience backstage devops team topologies self-service infrastructure dora metrics devex sre engineering leadership paved road developer productivity 2026

Frequently Asked Questions

Partager l'article

Twitter LinkedIn WhatsApp

Satyam Kumar

Founder & AI Architect, AppScale LLP

Architecte AI & Cloud. J'aide les équipes à construire des systèmes qui scalent pour des millions.

LinkedIn GitHub

Your Internal Platform Is a Ticket Queue With a Logo: Building an IDP Developers Actually Use

Frequently Asked Questions

Partager l'article

Comments

Leave a comment