Why Internal Developer Platforms Must Be Composable

The internal developer platform (IDP) market is expanding, and more tools are emerging as complete solutions to your platform needs. It’s tempting to believe that selecting one of these tools off the shelf will instantly make your team more productive. After all, who wouldn't want to skip the complexity of building something from scratch when there's a shiny, pre-packaged solution available?

The truth is, it’s not that simple and here’s why: Every organisation's infrastructure, compliance requirements, and development workflows are different and as unique as their business model.

This article explains why IDPs must be composable, allowing teams to design systems where parts can be added, replaced, or scaled to suit the organisation’s needs without rebuilding the entire platform.

Why the "buy" mentality fails with platforms

Many organisations rush to adopt IDPs by purchasing ready-made, bundled tools to solve all their problems quickly without considering the long-term implications.

However, this “buy” mentality becomes a problem because these tools tend to be opinionated or too rigid. They come with predefined workflows, assumptions, and constraints that may not align with every company’s unique infrastructure or needs.

For example, a tool designed primarily for cloud-native microservices might not be suitable for a company still running monolithic applications on-premises. This will lead to frustration, and developers may have to find other ways to bypass the platform entirely. So, instead of simplifying development, the platform creates complexity, and what was supposed to be a complete solution becomes a source of technical debt.

A truly effective internal developer platform must be flexible. It should allow teams to tailor the platform’s capabilities to their specific needs and support diverse workflows.

In other words, it should adapt to your organisation, not force your organisation to adapt to it.

Internal platforms are software products

Just like any customer-facing application, there are a few things that any IDP needs. 

The IDP Development Cycle

One of these things is continuous feedback from its users. Receiving regular feedback helps you identify issues early and determine which features require adjustment or expansion. Say developers often ask where to find logs—you could respond by adjusting the layout to highlight that section or by adding a shortcut for easier access.

From there, it’s all about iteration. Start with a basic version, then refine it gradually as you gather more input. For example, you might start with a basic deployment feature and later add automatic security checks as needed. 

Additionally, let’s not forget that every team works differently. Therefore, your platform should also support custom workflows tailored to their specific needs. They should be able to add or skip steps, use tools they prefer, or automate parts of their processes.

Finally, your platform should have a clear interface and be very easy to use. Tools like Backstage make this simple by offering an open source framework for building developer portals.

In essence, your internal platform should be built, not bought. They are infrastructure products, not one-off IT projects meant to be completed and forgotten.

Composability: The core of sustainable platform engineering

Composability means building your platform using modular, interchangeable components which you can rearrange or replace as needed. Instead of buying a fixed, all-in-one platform, you can build your own and choose which parts to use and how to connect them.

This approach enables teams to extend the platform over time, integrate open-source tools with custom solutions, and delegate ownership across multiple teams. Tools like ArgoCD for GitOps, Prometheus for monitoring, and AWS Secrets Manager to manage your secrets, etc. If one tool needs a change or an upgrade, you can replace it without affecting the rest.

So far, we've been talking about how you shouldn’t buy a platform and the utopia of being able to use any tool you want. The question then becomes, how do you translate this ideal into a reality?

What composable platforms look like in practice

A composable platform should provide “sane defaults” and be flexible enough to accommodate the needs of various teams.

A good example of providing sane defaults is the use of base manifests that you then customise for each team or environment. This is similar to the overlay pattern that Kustomize popularises, where you define common configurations once and then apply specific modifications as needed.

As a next step, consider a gradual introduction of custom resource definitions (CRDs). CRDs are great for introducing external resources that developers might need to run their workloads. A more concrete implementation might involve using Crossplane for provisioning an S3 bucket when a developer makes a request through a portal like Backstage. 

Combining this with the overlay pattern from earlier, you can start to build sane defaults that apply across your organisation as well as team-specific configurations. 

This is not to say you should reach for a CRD to tackle each new resource you need to deploy, especially when tools like Kratix have a library of Promises that contain many of the resources you need without you having to deploy an Operator.  

How Kratix enables true composability

Kratix helps you build your own platform using Promises. These Promises are contracts that let you turn any platform capability into a service that developers can request.

For example, instead of creating a support ticket for the ops team and engaging in a lot of back-and-forth (and handoffs to multiple teams) every time a Postgres database is needed, you create a Postgres Promise once. After that, developers just request an instance of the “Postgres Promise,” and Kratix takes care of the rest. 

You can also scale across different clusters. So, if you manage dev, staging, and prod separately, Kratix lets you deploy consistently without rewriting everything.

The best part about using Kratix to build your platform is that you choose your preferred tools and infrastructure and then wire them together declaratively.

Rather than buying a finished product and adopting a defined policy and structure, Kratix gives you the ability to build and customise yours.

Building platforms that last

Pre-built platforms might offer speed, but composable platforms offer control, flexibility, and long-term scalability. 

Wherever you are in your platform journey, if you focus on user needs, leverage the right frameworks (Kratix, Backstage, etc.) and tools (Crossplane, ArgoCD), and adopt a platform-as-a-product mindset, you can create powerful internal platforms that drive efficiency, reduce cognitive load, and accelerate software delivery.