Why companies fail at Internal Developer Platforms

Companies fail at IDP adoption due to education gaps. Even with tools like Backstage or strong Platform Engineering, success isn’t guaranteed without the right knowledge.

Understanding the education gap in IDP adoption

Many companies don’t fail to implement an Internal Developer Platform (IDP) because of a lack of technical skills - they fail because of an education gap. But this isn’t about mastering the technical aspects of how an IDP is built. The solution is simpler: understanding one step at a time. To grasp the core problem, let’s first explore how this education gap emerged in the first place.

The rise of Kubernetes and containerization

Over the past decade, containerization has become mainstream, especially among the G2000 companies (the world’s 2000 largest enterprises). What was once a buzzword is now standard practice, with Kubernetes as the foundation for container orchestration.

After 10 years (2014–2024), most companies have generally adapted containerization on the basis of Kubernetes. According to Gartner, by 2027, over 90% of G2000 organizations will be using container management tools for their hybrid environments, up from less than 20% in 2023.

Zooming out to 75%: How automation has evolved

However, much has changed in the last 10 years, especially in automation. Time hasn’t stood still just because companies have been focused on their immediate scope (Zoom 100%). If you zoom out by 25%, you’ll realize they haven’t reached the peak:  they’re still at the beginning of the climb.

We’ve moved beyond ClickOps and manual scripting to more advanced approaches like Infrastructure as Code (IaC) and Configuration as Code (CaC), enabling API-driven environments to be more maintainable. Over time, automation levels increased, and we transitioned from IaC toward composability and packaging, where individual services and components were abstracted for easier reuse.

From push-based deployments to GitOps

But that wasn’t the final step. Operators and orchestrators continued to evolve alongside Kubernetes, optimizing resource provisioning and management. This progress also changed how we handle deployments. What began with scripts evolved into CI/CD pipelines, initially relying on push-based deployment methods.

However, companies quickly realized that as release frequency decreased, the push-based approach introduced problems. Manual interventions created a growing gap between the desired state (in Git) and the deployed state in the real environment.

This led to the rise of GitOps and tools like Argo CD or Flux CD, which introduced pull-based deployments to close the gap. GitOps enabled more self-service-driven solutions, sparking the development of new tools and products. Understanding the shift from push-based to pull-based deployments is a critical part of closing the education gap. Without this knowledge, teams risk misconfiguring processes or relying on outdated deployment practices, leading to recurring failures.

Now, if we zoom out another 25%, we see even more changes unfolding.

IDP vendors are moving faster than enterprises

Portals like getport.io are considered runtime integration environments that provide the necessary tools to create compelling developer experiences.

Orchestrator-driven solutions such as Kratix or Humanitec allow you to integrate your tech stack, compose Kubernetes resources, and make them easily accessible to end users.

Open-source frameworks like Backstage enable you to build custom developer portals, giving product teams a self-service approach through a catalog.

Opinionated distributed IDP solutions like kubriX take a modular approach, leveraging open-source tools as a foundation while providing a predefined toolset through “Lego brick” components.

These different approaches and solutions aim to help companies build portals, integrate their existing tech stacks, or increase their level of automation. However, the outcome is often the opposite, especially when it comes to portal construction. A lot has changed, hasn’t it? And I wasn’t even talking about platformless solutions.

IDP and portal providers quickly noticed that the education gap varied in depth across companies, leaving many unable to keep up. As a result, several organizations fell behind. Vendors had to step in to provide guidance and education, as enterprises struggled to close the gap on their own.

How Minimum Viable Products (MVPs) can help bridge the education gap

How do you do it? Minimum Viable Products (MVPs) were created as lifelines to guide and support companies, kind of like a rebriefing. They help establish a shared baseline of knowledge, ensuring everyone understands the key concepts.

The approach of using MVPs was helpful - at least, it would have been, if many companies hadn’t rushed into creating Platform Engineering teams without fully understanding the discipline. These teams, often consisting of people who had previously managed infrastructure but never developed software, were suddenly tasked with building a platform as a product. This risky move led to frustration, especially when relying on frameworks like Backstage. While easy to deploy, companies quickly realized Backstage wasn’t the magical solution they hoped for.

Common pitfalls: Why companies fail

Buying SaaS products like getport.io, marketed as portal and runtime integration solutions, didn’t solve the problem either. The reason? Companies still had to handle the integration of their own stacks, a task they weren’t prepared for.

Many companies romanticized the idea of an IDP, believing it would solve all their problems with features like self-service, service catalogs, multi-tenancy, runtime integrations and so on. But once they committed to a solution, they were often shocked to find their existing stack wasn’t compatible, leading to disappointment and frustration.

Taking shortcuts without evolving their tech stack or addressing low automation levels (still stuck between ClickOps and scripting) only made things worse. Instead of solving problems, companies ended up with a fancy portal and an unnecessary complexity layer. Maybe a nice UI, but little actual functionality.

These failures are often rooted in the education gap. Without a clear understanding of how automation, integration, and self-service should work together, companies risk adopting tools that add complexity, without delivering business value.

When IDPs don’t deliver immediate value

For many companies, an Internal Developer Platform (IDP) or a portal didn’t provide much value immediately. In some cases, the skepticism was justified. Companies often labeled IDPs as a trend that added complexity without delivering tangible benefits. However, IDPs and portals can be incredibly valuable if you understand how to use them properly.

As Platform Engineers, we’ve seen this firsthand. Different groups, like the CNCF’s WG Platforms with its various pivots and versions, as well as Platform Engineering initiatives, have worked to understand enterprise needs. Online courses have also emerged to provide foundational knowledge and help companies align their understanding of key concepts. This is critical to avoid what happened with DevOps, where everyone claims to understand the term, but there’s no consistent definition.

From my experience working with experts and clients, closing the education gap isn’t about becoming an expert in building an IDP. It’s about developing a shared understanding within the organization!

Here are five key lessons I’ve learned during my projects that can help you build this foundation and tackle the education gap effectively.

Key lessons to build a strong IDP foundation

1. Establishing shared terminology

Sounds simple? It’s not. Go to different stakeholders and ask them what they understand by “cloud.” You’ll likely get different answers. The same issue arises here. The goal isn’t to invent your own terms that no one outside your organization understands. Instead, agree on a common terminology, ideally one that’s widely used in the industry. This way, when working with external partners or colleagues, you won’t have to waste time educating them on internal jargon.

Every time I run a workshop within a company, I dedicate 10–15 minutes to clarifying key terms to ensure everyone shares the same understanding.

For example, in my last project “Platform Engineering” refers to a team that provides the necessary services upon request and takes responsibility for their maintenance (upgrades, security patches, etc.).

Or consider the term “MVP”  -  what does it mean to everyone when we’re building one?

Important: Don’t judge or argue about definitions during this step. Otherwise, you’ll end up scheduling a second or even third workshop just to settle the debate!

2. Assessing automation levels

Many companies don’t fully understand their level of automation. I’ve often heard teams say, “We’re highly automated; everything is scripted.” Or, “We have everything 100% in IaC using Terraform modules.” Instead of judging this statement, I take it at face value and investigate further.

Here’s how I approach it: I ask the team to explain their bootstrap process in simple terms. I then break it down into individual building blocks and organize them into a very simple table.

If a company claims to be 100% automated but starts with 20% manual tasks as prerequisites, something doesn’t add up. This exercise often reveals gaps and areas for optimization before jumping into an IDP implementation or integration.

This step not only helps close the automation gap but also highlights missing workflows or steps between different stakeholders that need to be addressed.

3. Helm charts (catalog) are not an IDP

Let’s keep this brief: if you have a catalog of Helm charts, that doesn’t mean you have an IDP. Using Helm charts alone doesn’t provide a true self-service experience. Even if you have documentation, it still doesn’t qualify as an IDP.

Ask yourself how you plan to manage Custom Resource Definitions (CRDs) upgrades or Day-2 operations. You’ll quickly realize that while Helm charts can be part of an IDP, they’re far from sufficient on their own.

Why am I pointing this out? In one meeting, a team proudly told me they’d had an IDP for years and sent me their Helm charts along with documentation. When I spoke to the actual users, they said they didn’t use them because they were outdated, unmaintained, and it was easier to create their own umbrella charts. Clearly, that’s not a real self-service approach!.

‍4. The “developer” in Internal Developer Platform doesn’t mean only developers

Although the word “developer” is in the name, it doesn’t just refer to software developers. This distinction is important to make early on, because if you don’t include the right stakeholders, the platform you build won’t be used properly.

When I use the term “developer” in this context, I make it clear from the beginning that it includes all end users of the platform whether they’re security teams, FinOps, or service owners. Their needs must be considered when building the platform and gathering requirements.

You could call it an “Internal Platform,” but that would bring us back to the problem of unclear terminology (see Point 1).

5. The right abstraction layer

Not everything needs to be abstracted to the point where a single click magically deploys everything.

You need to decide on the right abstraction layer that everyone can understand. It won’t be the codebase itself, and if about 10% of the team doesn’t understand it, give them time to bridge that gap so collaboration on building an IDP becomes smoother.

In most of my projects, I’ve found success by agreeing on YAML manifests with developers, security teams, FinOps, service providers, and others.

Here’s what that looks like:

• For developers: When they deploy software, they know how to define services, ingress rules, deployments, etc. (especially if the system is composed).
• For security teams: They don’t need to understand the policy engine but can define their policies by creating YAML files.
• For FinOps teams: They can define budgets and alerts in YAML, using tools like KubeCost or OpenCost to handle the CD process. They don’t need to know the technical details, just how to specify values like $500 budget and a 90% threshold to trigger an alert sent via email.

The key is finding the right level of abstraction where each stakeholder knows their role without needing to dive into every layer of complexity.

Wrapping up: Why education is key

I hope this blog helps you understand how the education gap can do more than just lead to the wrong IDP choice. It can create unnecessary complexity, increase cognitive load on engineers, and fail to deliver real business value.

If you’re unsure where to start, it’s better to invest in a course rather than wasting your budget, only to realize later, “We’ve built something strange… and now we need help.”

Think about it: If you don’t know anything about finances, you wouldn’t blindly make big investments because the risk is too high. You’d either consult an expert or learn the basics. Why should it be any different here? The only difference is that you’re spending company money  -  not your own!