Spotify, Uber, Adidas, and other innovative companies are creating their own Internal Developer Platforms (IDP’s) as a bold move toward setting their future for success. Why is this becoming more and more of a trend? Well, an IDP promises to boost autonomy and efficiency, and hence accelerate time-to-market. However, as you can imagine, building a customized platform for your company is not a small decision – the amount of resources that you must devote to it is not negligible. Is it worth it? In this article, we will present the case for and against building your own IDP.

I. Introduction

An IDP consists of many different techs and tools, glued together in a way that lowers the cognitive load on developers without abstracting away context and underlying technologies. Following best practices, platform teams treat their platform as a product and build it based on user research, maintain and continuously improve it.

internaldeveloperplatform.org

So an IDP is indeed a product whose customers are the organization’s dev teams. It is important to emphasize this, as it will be the turning point where the platform becomes useful and starts giving back all the benefits we can expect:

• Developer autonomy, as the platform will allow for self-service, cutting back on wasted time due to dependency blocks.
• Faster releases, thanks to automating manual work that prevents developers from, you know, actually developing.
• Reduced cognitive load, as it frees developers from having to leverage a variety of technologies and tools.
• Standardization of the software delivery process via the creation of golden paths, which in turn will lead to cohesiveness, allow for reutilization, and foster collaboration.

Given that the platform’s customers are the organization’s dev teams, it becomes obvious that the IDP must respond to both the organization’s goals and its developers’ necessities. Most companies part from a brownfield setup and a series of detected bottlenecks at the time they consider using an IDP. Therefore, it seems logical that they will need a custom solution that matches the specificity of their uniqueness. Or will they?

II. The Case For Building Your Own IDP 

A. Customization 

As we’ve just pointed out, customization is an important factor to consider in building your in-house IDP. Cari Liebenberg from Container Solutions (@cari_za in Twitter X) explains that the first step when designing an IDP is to make sure that all the platform stakeholders align on the critical goal. Then, structure software teams to match the architecture they want the system to exhibit. The next step is to run a series of iterations of figuring out what value they expect from the platform, the requirements, and milestones with a single dev team and implementing them until there is a functional proof of concept. We don’t have the final product yet and the process is already as custom as can be.

Such a platform will meet all the organization’s needs. For example, working with the existing infrastructure, integrating with the tools already in use, promoting the goals that the stakeholders have set for it, and more.

B. Integration 

Maximum customization allows for perfect integration with previously existing systems. CI/CD pipelines, infrastructure… whatever tool or hardware the organization has already chosen can be part of the new platform if so desired. In the end, an IDP is the fundamental glue among a set of tools that work together.

Suppose that a company already uses Crossplane to enable developers to provision infrastructure using yaml files. The design of an in-house IDP can contemplate the use of Crossplane from the very beginning. This way, the organization makes use of existing know-how, translating into time and cost savings in the platform-building process. In addition, letting developers use a well-known tool, instead of making them learn to use yet another one, will help in effectively reducing the cognitive load and resistance to change.

III. The Case Against Building Your Own IDP 

A. Resource Intensive 

All the customization and integration that an in-house IDP may have comes at a price. If you choose to build your own IDP, you must designate a dedicated platform team. This team will not only design and create the IDP. It will have to get feedback from developers, address their issues and requests, implement improvements… all in all, maintain the product! Requirements fluctuate over time, so platform teams must implement changes regularly for platform adoption to be successful.

When weighing building vs buying, you need to ask yourself: How much money, time, and human resources can your organization distract from your core business to build an IDP from scratch? How long can your company wait before the triggering problems adversely affect your business? Though building such complex and custom software implies great variability from organization to organization, a rough time and cost estimation would be spending 2-3 years with a budget of at least $100,000 or $200,000. Be sure to account for overruns, too.

B. Expertise Requirement 

Another aspect to consider is the ability of your human resources to bring the building of the IDP to success. There are specific knowledge and skills requirements for this task, such as leadership, collaboration, UX design, integration, etc., in addition to expertise in every single piece of the future platform. Some companies, aware that they lack in this area, choose to hire specialized personnel for the platform team. However, for the folks in Adobe, it may not be worth it. When talking about their Adobe Experience Platform, a software aimed at personalizing customer experience, they explain: 

“We have encountered many companies that have spent 2–3 years building similar software, only to fall short of the requirements marketers need to use it. […] Handing off complex tasks that are beyond your team’s comfort zone will allow them to focus on what they do best, while a specialized company takes care of amplifying your team’s efforts and transforming your data into exceptional customer experiences.”

C. Updates and Improvements 

Finally, let’s remember that an internal platform is a product and, as such, needs maintenance. The platform team is here to stay, as they must take care of a series of tasks:

• update it according to changes in the organization’s architecture, needs, and goals
• ensure that the IDP always follows the latest security standards
• keep it up to date with the ever-evolving technologies
• improve usability to guarantee its long-term adoption
• fix bugs, edit obsolete components, integrate new tools, etc.

Unless you have a dedicated platform team or otherwise prioritize their duties accordingly, the IDP tasks may fall behind other work. Failing to maintain it appropriately will make it unuseful, not secure, and all in all a waste of effort, time, and money. If your organization is small, it may be wasteful to spend so much of your developers’ time on the platform, diverting it from your business core. 

IV. Alternatives to Building Your Own IDP

If you find that building an in-house IDP is not for your company, do not worry – Platform Engineering is already in the Gartner Hype Cycle. 

What this means for you is that you will be able to find a commercial IDP that will help you solve your organization’s bottlenecks without the commitment of resources that a custom one needs. It supposes an upfront but predictable expense that many organizations are willing to pay for a valuable tool that will be ready to use in almost no time.

Make sure to search for a platform that checks all these boxes:

• A one-size-fits-all IDP: a tool that seamlessly integrates with your existing tools and systems, whatever they are. Existing CI/CD pipelines, all major cloud vendors, multi-cloud, on-premise, bare metal… you name it.
• Pre-configured platform + customizable configurations: platform engineers will be able to effortlessly create your IDP. Maintenance becomes minimal because most of it is done by the provider.
• Full control and visibility: providing a central platform to view and share information about costs, management of the organization’s infrastructure, development progress, resource utilization, production bottlenecks, and overall system status.
• Promotes collaboration: it will boost efficiency and speed up time to market.
• Enforces security: look for an IDP that integrates standard Kubernetes RBAC and offers customizable security compliance levels for deployments.

After considering all these points, it’s clear that choosing the right IDP can make a substantial difference in your organization’s operations. It not only simplifies and streamlines the management of infrastructure but also catalyzes collaboration, promotes efficiency, and reinforces security. Napptive emerges as a truly robust and versatile option. It’s a fully featured, versatile solution, ready to go right out of the box. Make the choice that will empower your operations and elevate your team’s productivity to new heights. Try Napptive completely free here