You Don't Need an Internal Developer Platform. Yet.

TL;DR. The Backstage adoption graveyard is full of portals built before the foundation was ready. An IDP is the self-service layer on top of a platform that already works — it cannot fix a fragmented CI/CD pipeline, inconsistent infrastructure patterns, or golden paths no engineer chose voluntarily. Five prerequisites must exist before a portal adds real value: consistent infrastructure, a CI/CD pipeline that works the same way for everyone, at least one golden path engineers choose without being forced, a platform team with product capacity, and a measurement baseline. If any of these is missing, build that first. The portal can wait.

A CTO I spoke with last year told me his team was building an IDP because Spotify had Backstage and Netflix had their platform, and his engineers kept complaining about too much friction. So they hired two platform engineers, stood up a Backstage instance, and six months later had a beautiful developer portal that approximately twelve people used, mostly to look up service ownership before going back to Slack and asking someone the same question they always asked.

This is not a unique story. I have heard some version of it from engineering leaders at companies across financial services, healthcare, and enterprise SaaS. The desire to build an internal developer platform is real, the investment is real, and the adoption is frequently catastrophic.

The problem is almost never the technology. It is the sequence.

An IDP is a product your platform team builds, not a tool you install

An internal developer platform is not a tool you install. It is a product your platform team builds and maintains for your engineering organization as its primary customer. That distinction matters more than anything else in this post.

Backstage is a framework. Cortex is a product. Port is a product. What you build on top of them, the workflows, the golden paths, the service catalog, the self-service actions, all of that is a product that requires a product manager mindset, ongoing investment, user research, and a support model. Most engineering teams start with the framework and forget the rest.

When Spotify built Backstage, they had roughly 200 engineers working on infrastructure and developer experience. They had already solved consistency at the platform level. The portal was the last layer on top of a foundation that worked. When a mid-size company with three platform engineers tries to replicate that, they are building the last floor of a building that does not have walls yet.

Why Backstage adoption craters — and what the pattern reveals about sequence

Search "Backstage adoption" in any platform engineering community and you will find the same pattern repeated. A company stood up an instance, populated it with a service catalog, added a few TechDocs pages, and then watched adoption plateau at the teams who were already paying attention to documentation anyway. The developers with the most friction, the ones who actually needed the help, never came back after the first visit because the portal could not do anything useful for them.

Why? Because the thing those developers actually needed was not a portal. It was self-service infrastructure provisioning. Consistent deployment pipelines. An on-call handoff process that did not require reading six internal wikis. Golden paths for spinning up a new service without asking the platform team to hold their hand through three Terraform modules and a Jenkins configuration they had never seen before.

The portal is the front door. You cannot build the front door before you have a house.

Five prerequisites that must exist before an IDP delivers real value

Before an IDP can deliver real value, your organization needs five things. Not all of them have to be perfect, but all of them have to be functional. If any one of them is missing or severely broken, your IDP will paper over the gap for a while and then collapse under the weight of the workarounds.

The first is a consistent platform foundation. This means your infrastructure is managed as code, your Kubernetes clusters or equivalent container runtime behave the same way across environments, your networking and identity management follow a standard pattern, and your secrets management is not four different tools used by four different teams based on personal preference. If engineers deploy to production differently depending on which squad they sit in, you do not have a platform yet.

The second is a CI/CD pipeline that works the same way for everyone. Not similar. The same. One of the early signals I look for when evaluating platform readiness is whether a developer joining a new team can understand the deployment pipeline within an hour. If the answer is no, you have an integration problem, not a portal problem.

The third is at least one golden path that people actually use voluntarily. A golden path is a pre-built, opinionated way of doing something. Not a recommendation. A path with guardrails that gets you to a working, compliant, observable service in a predictable way. If you have to force engineers onto your standard templates, the templates are not good enough or the platform underneath them is not trustworthy. When engineers choose the golden path because it is faster, you are ready to build more on top of it.

The fourth is a team that can operate as a product team. This is the most commonly underestimated requirement. Platform engineering is not a better name for infrastructure. It requires prioritizing features based on developer feedback, measuring time-to-productivity for new joiners, tracking which self-service actions save the most engineering hours, and making deliberate tradeoffs about what to build versus what to keep manual. If your platform team spends more than 40 percent of its time firefighting support requests, it cannot build a product. It is a support desk with ambitions.

The fifth is a baseline. You need some measurement of where you are before you build the platform, otherwise you will never know if the platform is helping. DORA metrics are the standard: deployment frequency, lead time for changes, change failure rate, and mean time to recovery. You do not need perfect data. You need enough to say "lead time is roughly three days and we want it under one" so that six months after the IDP launches, you can check whether it moved.

Four signals that your organization is not yet ready for an IDP

You are not ready for an IDP if your platform team gets more than twenty support tickets per week from developers asking how to do things that should be self-service. That is not a portal problem. That is a platform foundation problem, and a portal will make it more visible without making it better.

You are not ready if different teams use different tools for the same job with no plan to converge. If team A uses GitHub Actions, team B uses Jenkins, and team C has something a consultant built two years ago that nobody fully understands, the first order of business is not an IDP. It is the CI/CD standardization that makes an IDP possible.

You are not ready if you cannot answer the question "how long does it take a new engineer to deploy their first change to production?" If nobody knows, you do not have a measurable developer experience problem, you have an unmeasured one, and platforms cannot fix what they cannot see.

You are not ready if your platform engineers spend most of their time on reactive work. An IDP built by a team that is already underwater will be under-featured, under-documented, and will create new support burden on top of the existing one.

Three signals that your organization is ready to build the portal

You are ready for an IDP when your platform team is getting the same five questions from different teams and knows exactly what the answers should be, but cannot automate the answers because the tooling is too fragmented. That repetition is exactly the signal an IDP is designed to eliminate.

You are ready when at least one golden path exists and engineers are choosing it, but the path requires too much manual coordination to scale to the next team that onboards. The portal makes that coordination self-service.

You are ready when you have a stable platform foundation and developers trust it. Trust matters here. If engineers routinely work around the platform instead of through it, the problem is credibility, not features. An IDP built on an untrusted platform will be ignored.

You are ready when you have a platform team that has the capacity to treat the IDP as a product with a roadmap, user interviews, and support SLAs. Two engineers in their spare time cannot build and maintain a platform used by two hundred developers. Platform engineering requires dedicated investment, not good intentions.

The build sequence that produces IDP adoption instead of a Backstage graveyard

The organizations that build successful IDPs do not start with the portal. They start with the foundation.

They establish consistent infrastructure patterns across teams. They standardize the CI/CD pipeline. They build one or two golden paths and get engineers actually using them. They instrument the platform with enough telemetry to see where friction lives. Then, once all of that is working, they build the portal as the self-service layer on top of the foundation they have already proven.

Backstage or any other IDP framework becomes genuinely powerful at that point, because the catalog is reflecting real services with real ownership, the golden paths in the portal are backed by working automation, and the self-service actions actually do something instead of opening a Jira ticket that eventually gets to a human.

The typical timeline for getting a platform foundation to the point where an IDP adds clear value is six to nine months for a focused team. Not because the work is complicated, but because you need time to validate each layer before building the next one. An IDP built on top of a foundation that is still being stabilized will absorb the instability.

One diagnostic question that tells you which phase you are actually in

Before you write a ticket for Backstage, ask your platform team this: if I am a new engineer joining any squad in the company today, what do I need to do to deploy a change to production, and how long will it take me?

If the answer varies significantly by squad, start with the foundation. If the answer is consistent but takes longer than a day, start with the golden paths. If the answer is consistent and fast but developers are still asking the same questions repeatedly, that is when you are ready to build the portal.

Most engineering organizations I work with land in the first or second category. Not because they are behind, but because they have been focused on shipping features, which is the right priority when you are growing. Platform investment tends to happen reactively, after the pain is already visible. That is fine. What matters is doing the work in the right sequence when you decide to do it.

The IDP can wait. The foundation cannot.

What building foundations before the portal looked like at a 340-engineer org

A financial services company I worked with had been running Backstage for eight months before they engaged us. They had 340 engineers and a platform team of four. The catalog had 180 services listed. Roughly 30 of them had accurate ownership information. TechDocs pages existed for 40 services. Twelve of those were current.

The deployment pipeline differed between their legacy banking product and their newer API layer. The Kubernetes clusters used different ingress controllers across environments, which meant the platform team was manually handling deployment exceptions every week. There was no standard for secrets management. Three teams used Vault, two used AWS Secrets Manager, and one team had a creative arrangement involving a shared Google Doc that I will not describe in detail.

The portal was not the problem. It was a symptom of building the presentation layer before the data and infrastructure layer were ready. We spent four months on platform foundations before touching Backstage again, and when we did, adoption went from twelve regular users to over ninety in six weeks, because the self-service actions finally did what they promised.

How the Foundations Assessment tells you which phase you are in before you commit

At Clouditive, we built the Foundations Assessment specifically because the IDP conversation needs to happen before organizations commit to the portal build. The assessment gives you a maturity radar across all five pillars: Platform Foundations, Delivery Engineering, Reliability and Operations, Observability and Insight, and Developer Experience.

If you are thinking about an IDP and want to know honestly whether you are ready, the assessment is a 15-minute deep dive that tells you where the gaps are before you spend the budget. You can take the Free Platform Score here without talking to anyone.

If the radar shows you have the foundation and delivery engineering pillars at level three or above, you are in a real position to start planning an IDP. If they are at level one or two, you know what to work on first. The assessment does not tell you what you want to hear. It tells you what you need to know.

For organizations that do have the foundation and want to move forward on an IDP, our IDP Delivery engagement pattern covers the Blueprint and Forge phases across Developer Experience and Observability. It is designed to build the platform your engineers will actually use, not the one that looks good in a demo.

The team design problem that stalls IDPs before the first golden path ships

There is a team design issue that sits underneath all of this and almost never gets discussed in IDP conversations.

An IDP requires a platform team that operates as a stream-aligned enabler. In Team Topologies language, this is an enabling team or a platform team that reduces cognitive load for stream-aligned teams. It is not a team that owns every deployment and fields every support request. The model requires platform engineers who build products and then get out of the way, not platform engineers who become the critical path for every change.

Most organizations that want to build an IDP have a team that operates as a complicated subsystem team or an enabling team that has not yet made the transition to building self-service. The difference in how the team spends its time is stark. A team still operating in the old model spends most of its time responding to requests, fixing environment issues, and helping teams navigate the complexity it has not yet automated away. A platform team ready to build an IDP spends most of its time on the product: the golden paths, the self-service actions, the catalog, the documentation.

If you try to build an IDP while the team is still in reactive mode, the IDP will be starved of the investment it needs to succeed. The portal will launch with half the features it promised, the documentation will be incomplete, and the self-service actions will have undocumented edge cases that send developers back to Slack anyway.

The team design question is worth answering honestly before the IDP conversation starts.

What IDP vendor demos show — and what they are not telling you

One last thing. Every IDP vendor will show you a demo of a beautiful portal with a service catalog, a tech radar, TechDocs, and one-click scaffolding for new services. The demo will work perfectly. The scaffolding will spin up a service in thirty seconds. The catalog will have clean ownership data.

That demo is real. It is also running against a purpose-built demo environment that has been configured to work exactly that way. Your environment has twelve years of accumulated decisions, three different CI/CD systems, five Kubernetes cluster configurations, and at least one team that has never heard of the internal platform initiative.

The demo shows you what is possible when the foundation is right. The question is whether your foundation is there yet.

If you are not sure, find out before you start. That is the entire point.

Related reading

• Why IDPs fail — three patterns — the three specific failure patterns that follow when teams skip the prerequisites described here.
• IDP build vs. buy — how to decide without regretting it — once the prerequisites are met, how to evaluate Backstage versus purpose-built versus custom without the wrong criteria.
• Golden paths developers actually choose — prerequisite three in practice: what makes a golden path something engineers choose rather than avoid.
• The platform engineering mistake that cost $2M and two years — a detailed account of what happens when the adoption prerequisites are skipped.

Frequently asked questions

What are the five prerequisites an engineering org needs before building an IDP?

A consistent platform foundation (infrastructure managed as code, environments that behave the same way, a standard secrets management approach). A CI/CD pipeline that works the same way for everyone. At least one golden path that engineers choose voluntarily, not because they are required to. A platform team with capacity to operate as a product team — not more than 40 percent of their time in reactive support. And a measurement baseline: DORA metrics or equivalent, so you can tell whether the IDP is improving delivery after it launches.

Why does Backstage adoption crater at so many companies?

Because they build the portal before the foundation exists. Backstage is a framework. The self-service actions in the portal need something real to call: a consistent deployment pipeline, working infrastructure automation, golden paths with actual guardrails. When those things are not there, the portal creates a front door that opens onto nothing. Engineers visit once, find that the "self-service" action opens a Jira ticket, and go back to Slack. The portal is the last layer on top of a foundation that has to work first.

How long does it take to get a platform foundation ready for an IDP?

Six to nine months for a focused team, based on repeated experience. Not because the work is technically complicated, but because each layer needs to be validated before building the next one. An IDP built on a foundation that is still being stabilized will absorb the instability — adoption will crater, and you will spend platform team time on support instead of building the product. The timeline is worth accepting because the alternative is a Backstage graveyard.

What is the difference between a platform team that is ready to build an IDP and one that is not?

A platform team ready to build an IDP spends most of its time on the product: golden paths, self-service actions, catalog maintenance, documentation. A team not yet ready spends most of its time on reactive work: fielding support requests, fixing environment issues, helping teams navigate complexity that has not been automated. The 40 percent reactive threshold is the practical signal. If your platform team is above it, build the foundation first. The IDP will not succeed while the team is a support desk with ambitions.