Build a successful Internal Developer Platform

Build a successful IDP (Internal Developer Platform)

These days you can hear statements like: “Platform Engineering is the new DevOps” or “Every successful IT company needs to have an internal developer platform”. But why exactly are people hyping these topics so much lately?

To save your time: This article will not dive into technical depths or compare tools. There are a lot of resources for this already. Instead I will try to put a light on the ‘why’ behind platform engineering and internal developer platforms as well as factors that help being successful building one.

To understand the ‘why’ we need to take a closer look on how things have developed over the last 20 years.

A short history of…

DevOps

DevOps emerged in the late 2000s as a response to the growing disconnect between software development (Dev) and IT operations (Ops). Traditionally, developers focused on writing code, while operations teams were responsible for deploying and maintaining it. This siloed approach often led to inefficiencies, miscommunication, and slower delivery cycles.

The term “DevOps” was popularized around 2009, driven by movements like the Agile Manifesto and the need for faster, more reliable software delivery. Early pioneers, such as Patrick Debois and Gene Kim, emphasized collaboration, automation, and continuous integration/continuous delivery (CI/CD) pipelines. DevOps aimed to break down silos, foster a culture of shared responsibility, and streamline the software development lifecycle.

Platform Engineering

Platform engineering began gaining traction in the mid-2010s as organizations faced increasing complexity in their infrastructure and tooling. While DevOps focused on cultural and process improvements, platform engineering emerged to address the growing need for scalable, reusable, and developer-friendly platforms.

The rise of cloud computing, containerization (e.g., Docker, Kubernetes), and microservices architectures created a demand for centralized platforms that abstracted away infrastructure complexity. Platform engineering teams began building internal developer platforms (IDPs) to provide self-service tools, standardized workflows, and automation, enabling developers to focus on writing code rather than managing infrastructure.

By the 2020s, platform engineering became a distinct discipline, complementing DevOps by operationalizing its principles through dedicated platforms. It focuses on creating a “golden path” for developers, ensuring consistency, efficiency, and scalability in modern software delivery.

So in the beginning we had developers throwing stuff over the wall to some operations team(s). Then with DevOps we made them operate what they built and caused mental overload and a hundred different ways of doing the same thing in a single company.

An internal developer platform — this is my interpretation — is the try to take some of the mental load from the development team by creating one central platform for all development teams. The approach also brings the benefit of standardization, so there will be just a few streamlined and secure ways of doing things.

Building a successful internal developer platform

An internal developer platform is the product that a platform engineering team builds for its customers. These customers are primarily the company’s developers.

So in order to be successful the product needs to fit the customers. If developers are not happy with the platform they might only use it because a company policy forces them to but will immediately stop using it as soon as they find ways or reasons to do so.

So how can you as a platform engineer be sure that your product is fitting your customers?

Solve a pain

When you start, your platform has to take the everyday life of your developers into account. How are they working and what would be a thing that they were more than happy if they no longer needed to take care for? Solve it for them and let this be the first feature of your platform.

Start small

You don’t have dashboards yet. That’s ok, just be honest and transparent with your developers. Tell them what you are working on at the moment that prevents you from delivering the one feature that they are craving for so much. Create tickets for that feature in your backlog and try to implement it as soon as time allows.

Support and maintenance

Don’t let your customers down. They are using your platform and trust, that you help them doing day two operations. Maybe you don’t have everything automated yet; that is not nice but also not the biggest issue. Simply help with ways how they can do what they need to do and then integrate those quick and maybe hacky solutions. With each week the numbers of features in your platform will increase.

Be transparent

I can’t emphasize enough that transparency is extremely important. To gain this transparency invite your developers to your sprint review. Show them progress. If they may not have gotten their most wished feature, it helps if they see that you solved something else which would have been a huge risk of having an outage.

Another thing that might help is having a weekly meeting of about 15 to 30 minutes with your developers and platform engineers where you just honestly talk about things that both sides are currently doing. If someone had a hard week because there was a major outage they should exactly talk about that. It greatly helps gaining an understanding for the challenges and pains of the others and builds up trust and a positive relationship.

Developers are used to fix their problems by themselves. They use libraries and services if they are reliable, maintained and do not stand in their way. As soon as they find out that there is a limitation that they can not get rid of themselves, by asking for help or create a pull-request, they will drop that dependency and move on to use something else.

As a platform engineer you need to develop a product mindset. The APIs that you communicated to your customers need to stay stable no matter what. If your documentation describes a certain way than this way has to work out. Make sure you have automated tests in place. Closely listen to what your developers are saying. For them to be honest with you, you need to have built up and to maintain a relationship of trust.

So in the end it doesn’t really matter that much if you are using ArgoCD or Flux or what kind of ingress controller or service mesh you are using. It’s important that the internal developer platform solves problems without causing more problems than it solves.

The future (if you are successful)

If you are successful you will get other customers as well:

• Security teams which will want to scan workloads and traffic for known vulnerabilities and anomalies as well as deploy policies that guardrail your developer teams. Be sure to help your security colleagues to be transparent to your developers so that they do not get surprised by new policies.
• Controlling teams, which will want to have insights into where all the expenses are going to. Help them by enabling your developers to tag their resources with project or customer names so that you can visualize the expenses accordingly in dashboards for your financial controllers.

Conclusion

Maybe my other articles may also helping you focus on the problems of your developers by maybe stop saying DevOps and Platform engineering and also think about when not to use kubernetes.

I hope my thoughts and experiences are of value to you. Let me know which experiences you made, especially how you are establishing and keeping up a good relationship to your development teams.