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

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.

What an IDP Actually Is

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.

The Backstage Graveyard Is Real

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.

The Five Things That Have to Exist First

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.

Signs You Are Not Ready

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.

Signs You Are Ready

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 Sequence That Actually Works

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.

The Question to Ask Your Team Right Now

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 This Looks Like in Practice

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.

The Foundations Assessment Exists for This Reason

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 Topology Problem Nobody Mentions

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.

A Note on Vendor Demos

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.