Why Companies That Built Internal Dev Platforms Wouldn’t Do It Again

Operational tasks like scaling and provisioning resources shouldn’t be developers’ focus. Instead, prototype building and feature additions should be the core of their daily work. That’s the exact reason why companies ultimately decide to build an internal developer platform (IDP), so they can lift the burden from development teams. 

Yet, organizations that went on the IDP path convinced it would be the answer to their problems eventually concluded it didn’t bring them the estimated benefits. Moreover, an internal developer platform had the opposite effect and created a string of issues and frustrations. 

Let’s see the top 6 reasons why companies who chose to build an IDP abandoned the idea and established buying an internal dev platform is a better fit for them.

With ownership comes pride in your team’s work. Additionally, companies follow this approach: it’s best that everything customers or users directly access it’s created in-house by their teams. That’s because companies know their customers better than anyone, and they also get to bring uniqueness to their business.

In theory, an internal developer platform should have these end results: 

In practice, things don’t always match the theory. Keep reading, and you’ll find out why.

An internal dev platform’s functionalities and promised guarantees sound like a dream on paper. But companies must take into account several factors before fast-tracking their way into such an intense project. Take it from companies that went through this experience and see below the main reasons they wouldn’t do it again.

Let’s face it! Whether built or bought, along with each idea of a new tool, the cost is a prime concern or sometimes an obstacle. And that statement is true even for large organizations where money isn’t an issue. Building an IDP means spending a lot on equipment, resources, training, etc.

Still, after they’ve invested time and money, companies realized an IDP isn’t worth it for reasons like:

Building a developer platform means you can automate and simplify processes and remove the burden of unnecessary work. Still, some companies that engaged in this initiative didn’t realize IDPs are hard to build, manage, and keep updated. For instance, internal dev platforms require constant maintenance to ensure:

Unless the IDP’s processes are well-crafted, every time a company adds new applications, services, and clusters, there comes the need to add changes to the IDP.

This is an ugly truth but, nevertheless, a common occurrence when building in-house platforms. In most cases, no one wants to take full responsibility for the project. As a result, most developers won't give the local platform the attention it requires. Developers and engineering teams will see it as a one-time side project made of assembled custom scripts instead of considering it an actual product.  

Ideally, local dev platforms should have a dedicated support team that frequently interviews developers, addresses their issues and requests, and creates a specific roadmap for improvements. Unless these actions aren’t performed regularly, developers will never successfully adopt the IDP.

Any IT department wants to align with a governance model covering automation tools for specific system or process issues. With an IDP, applying different levels of control and governance depending on each team and service isn’t exactly a piece of cake. Nowadays, DevOps and platform engineering teams have to implement controls and custom scripts across security, RBAC, network policies, resource consumption, and more.  

Once teams find this step challenging, developer platform projects will suffer and won’t be successfully completed.

Developers’ quick adaptability is a given, but extending this quality to the platforms they’re building can be a dangerous mindset. Many times, after they have created their in-house platform, developers realize their platform integrates adaptive capabilities that may serve them perfectly today. Still, these capabilities’ utility will likely decrease over time or even become obsolete. 

The ‘perfect’ internal development platform must also be prepared to integrate with new development tools, leverage new infrastructure, and address additional requirements (mostly at the organization level).

Creating an internal dev platform requires more than just code deployment; it also means crafting a robust continuous operational model with the right connections between Continuous Integration, Delivery, and Operation. Frequently, development teams focus solely on Continuous Delivery and omit to go further, failing to monitor its performance and all operational aspects after deployment. 

Ultimately, developers who fail to ensure the IDP has the desired impact, either abandon it or do more work trying to adapt it so it satisfies the company’s needs.

After failing to build a perfectly suitable internal dev platform, companies are back to square one, and developers face low speed and agility. Despite your developers’ advanced skills and unless your team sets clear and straightforward processes and responsibilities, in-house development can prove to be a time-sink with several limitations.

The bottom line is: building an internal developer platform may work well for small internal apps, like the ones built on top of a company database. When it comes to more complex, high-level functions (e.g., CRMs or account platforms), building from scratch is usually not worth it.

A viable option is an Environments as a Service solution. Try out Bunnyshell - an easy way to deliver development infrastructure and services. You can run applications within on-demand ephemeral environments. Bunnyshell removes the burden of creating custom scripts and managing complex software. 

Set up CI/CD pipelines, automate the deployment chain, and get shorter deployment cycles while instantly replicating your testing, development, staging, and production environments.

With EaaS, you’ll have an engaged engineering team - the best asset any company can have.