Building an Internal Developer Platform: The Harsh Reality Behind the Promise

Many companies are enticed by the idea of building an internal developer platform (IDP)—a software that combines all the systems developers use into a unified experience.

​IDPs provide developers with the infrastructure, tools, and workflows required to build, deploy, and monitor applications efficiently and at scale. However, building an IDP often fails to live up to the vision.

Companies invest substantial time and money into developing IDPs, only to realize it isn’t the optimum use of their resources. This article will examine the gap between the promise and harsh reality of building internal developer platforms and why buying an extensible IDP is more practical.

Why Are Businesses Building IDPs?

Why do companies pursue building internal developer platforms in the first place? At first glance, the potential advantages seem compelling:

• Automation - IDPs promise to automate repetitive processes like environment setup, configuration, and tear-down. This saves engineering teams time and speeds up workflows.
• Accelerated release cycles - With an automated platform for testing and deployment, companies expect to deploy updates and new features faster.
• Enhanced security - Companies believe purpose-built internal platforms will provide tighter security controls and safeguards than third-party solutions.
• Customization - Building a platform in-house allows companies to customize it to their specific needs and workflows.
• Control - Companies like owning the end-to-end process rather than relying on third-party vendors. Building a platform in-house provides greater control.
• Cost savings - Some companies believe internal platforms will save money compared to licensing and managing third-party services.

These potential benefits align with key business goals: faster time to market, increased efficiency, and cost savings. However, the reality of executing these goals via an internal platform often needs to be clarified. Let’s understand the actual costs of building an IDP vs. buying one.

9 Reasons Building an IDP Isn’t The Best Solution for Businesses

Developing an internal developer platform requires a significant upfront investment. The software, engineering resources, and other costs add up quickly. Ongoing maintenance and operation costs are also higher than expected. Let’s look at some of the actual costs behind building an IDP.

1. Complexities of IDPs

Internal developer platforms promise to reduce complexity for engineering teams by providing a unified and automated environment. But in reality, building and managing an IDP introduces daunting complexity, which often backfires.

Customizing, integrating, and operating complex infrastructure components like Kubernetes, service meshes, ingress controllers, and CI/CD pipelines is incredibly challenging. There are countless moving parts and dependencies that have to work together seamlessly.

Rather than accelerating releases, an over-engineered internal platform can impede productivity as engineers waste time-fighting fires related to the underlying infrastructure.

The bottom line—building an IDP from scratch is a complicated undertaking. If you do take it up with limited resources, the slow updates and high upkeep can negate the developer productivity benefits of an IDP and add to resource wastage.

2. Technical Debt Accumulation

Internal developer platforms built in-house slowly accumulate "technical debt" over time. This debt eventually makes the platform unstable, insecure, and expensive.

• For example, outdated third-party libraries or frameworks used in the platform become security liabilities needing urgent upgrades. But constant upgrade projects drain engineering resources.
• Other debt comes from engineers taking shortcuts or bypassing best practices to match developer agility. This piles up as debt requiring future refactoring or a complete system overhaul.
• Insufficient documentation— Often inadequate or outdated documentation of in-house built IDP leads to misinterpretation of features and capabilities.This slow accumulation of technical debt starts minor but eventually compounds into significant issues. And the platform team needs to constantly firefight to keep the platform operational.

3. Time Sink of IDPs

Developing IDPs requires extensive time investment that prevents focus on core products. For example, Treebo found developers wasted time maintaining complex in-house deployment tools, driving lengthy production troubleshooting cycles, and taking ~80% of ops time.

"The biggest challenge for the Ops team was that they would spend 70-80% of their time-solving production issues or helping the development teams debug; this was frustrating for both teams. The team's turnaround times would inevitably increase because of this." - Kadam, Co-Founder & CTO, Treebo.

Rather than expediting releases, building an IDP can seriously impede engineering productivity and velocity if attention is diverted from core product development.

4. Limited External Integrations

Custom-built internal platforms often struggle to integrate smoothly with external tools and systems. This contrasts commercial platforms designed from the ground up for extensibility.

• Internal platforms use isolated architectures that conflict with existing systems. There's no consideration for standard integration patterns.
• The platforms aren't designed for extensibility. The focus is only on internal use cases.
• It takes specialized skills to build well-documented, stable APIs enabling external integrations. Many internal teams lack these skills.
• Mismatched version dependencies multiply integration complexity. Commercial platforms actively support integration within rich partner ecosystems. Phrase better: Integrate once is not enough because an IDP underneath uses multiple tool integrations, upgrading integrations constantly with the version upgrades of those tools is a daunting task

The point is—poor integrations cripple adoption. Engineering teams default to previous tools incompatible with the new platform, and the platform fails to reach critical mass.

5. Security Risk of DIY Platforms

Phrase better: IDPs integrate with sensitive tools in business critical path like cloud, release management etc. Any breach will be catastrophic and hence mitigating security risk is paramount.Ensuring enterprise-grade security with internally built developer platforms is remarkably challenging. DIY platforms can expose organizations to breaches and outages without rigorous controls and processes. Unlike commercial solutions designed for security, DIY platforms often lack things like:

• Granular access controls
• Change & Upgrade management
• Hardened architectures
• Audit logs
• Automated security testing

Internal developer platforms frequently fail to meet enterprise infrastructure's stringent security and availability standards. DIY approaches expose organizations to potential breaches and outages without security woven into the platform.

6. Governance and Compliance Challenges

Implementing robust governance processes presents difficulties for many companies using homegrown IDPs. For example:

• Access controls - Ensuring developers have appropriate permissions and limiting access is complex to manage in DIY platforms.
• Policy enforcement - Enforcing security, operational, or regulatory policies programmatically across all systems connected to the IDP is challenging.
• Auditability - Many IDPs lack tools to monitor access, changes, and logs needed for audits.
• Compliance - Adhering to regulations like HIPAA or PCI is difficult without proper compliance-oriented controls built into the IDP.

As companies scale, these governance issues become exponentially more challenging.

7. Ignoring Post-Deployment Management

Many internally built IDPs focus heavily on deployment automation while ignoring critical post-deployment aspects that impact developer productivity and system reliability.

IDPs built in-house often lack the following:

• Observability into application and infrastructure performance via logging, monitoring, and metrics.
• Troubleshooting capabilities like search and analytics to quickly resolve issues.
• Incident response features like automated alerting and runbooks.
• Performance management to track and optimize applications.
• Cost optimization through real-time visibility and anomaly detection.

As a result, developers fly blind after deploying new versions, leading to more application downtime and incidents.

In contrast, purpose-built vendor platforms integrate deployment automation with robust operations capabilities out-of-the-box. Companies must carefully evaluate post-deployment functionality if choosing to build IDPs internally versus leveraging commercial solutions designed for production operations.

8. Constant Updates and Maintenance

Maintaining and constantly updating an internally built developer platform significantly adds to the total ownership cost over time. Consider factors like:

• Platform upgrades and migration - Major upgrades to core components like Kubernetes or migration to new infrastructure often require substantial engineering effort for an internal platform. Commercial platforms handle upgrades seamlessly behind the scenes.
• New feature development - Adding new capabilities to meet emerging needs involves dedicating precious engineering resources. Vendor platforms deliver continuous innovation through new feature releases.
• Bug fixes and patches - Bugs and security vulnerabilities need rapid fixes and patches to avoid disruptions. DIY platforms lack processes for swift resolution.
• Custom integrations - As new tools and technologies emerge, custom integrations must be built and maintained on the internal platform.
• Technical debt servicing - The accumulating technical debt makes the platform unstable and expensive. Refactoring and rearchitecting are constant chores.
• Opportunity cost - The ongoing cost of maintaining the platform soaks up resources better spent on developing core products and innovations.

The long-term maintenance and update costs compound over time into a massive total cost of ownership for internal developer platforms.

9. Difficulty Retaining Specialized Expertise

Running an internal platform requires specialized expertise in infrastructure automation, APIs, security, integrations, and other complex domains. These skills are scarce, expensive, and challenging to retain in the long term.

Constant recruiting, training, and transferring tribal knowledge as experts leave can become an impossible burden. Dependence on irreplaceable personnel is an Achilles heel.

In contrast, external vendors concentrate deep expertise across large teams to continually advance their platforms. This makes stability and continuity impossible for internal platform teams to match.

So, retaining specialized skills and knowledge is challenging for internally built and managed developer platforms.

What to do Instead of Building an IDP?

Rather than investing months or years in building an internal platform, off-the-shelf solutions provide a faster path to boosting developer productivity and innovation velocity.

Prebuilt developer platforms like Facets give you the following:

• Accelerated time-to-market: Get a unified automation platform out of the box instead of waiting months for custom builds.
• Improved focus: Developers stay focused on building products vs. maintaining platforms.
• Optimized environments: Built-in best practices for security, reliability, and cloud optimization.
• Increased collaboration: Platforms like Facets connect siloed teams for better visibility.
• Future-proof foundation: Continually enhanced platform vs. stagnant homegrown code.
• Reduced costs: Avoid expensive hiring for specialized platform skills.

Purplle evaluated solutions like Facets which provided environment automation, collaborative workflows between teams, and cloud optimization. This allowed Purplle to reduce time-to-market by 25X and cut cloud costs by 70%. Building an internal developer platform in-house is challenging—steep complexity, soaring costs, and frustrating delays. There's a better way.

Facets provides a unified, self-serve infrastructure automation platform designed by DevOps experts. It integrates deployment, configuration management, observability, and more into one solution.

With Facets, you get reusable blueprints to launch multiple identical environments with a click. It centralizes visibility so everyone works from a single source of truth. Facets also free up your Ops team from repetitive tasks so they can focus on innovation.

Companies like Purplle, Treebo, and Capillary transformed delivery using Facets to increase developer productivity by 20%, reduce ops tickets by 95%, and accelerate time-to-market by 25X. Shift gears on innovation and start shipping value faster to customers with Facets.

See for yourself—get a demo today.

FAQs

What are some signs that an internal developer platform is failing?

Indicators include engineers complaining about platform reliability issues, rampant bugs, steep learning curve, lack of use among developers, platform-related delays in deployments or releases, and escalating financial costs.

How long does building an internal developer platform typically take?

For most companies, 18-24 months is a typical timeline from initial planning through a minimal viable product launch. However, it often takes 12 additional months to work out bugs, stabilize the platform, and gain adoption across the engineering org.

Is building an internal developer platform worth the effort and cost?

In most cases, no. The risks, complexity, and costs often outweigh potential benefits compared to proven third-party solutions like Facets designed specifically for developer workflows. It allows extensibility so your IDP, even though not built internally, adjusts to your existing workflows instead of your team adjusting to a new workflow.

What are the most important things companies overlook when evaluating internal developer platforms?

Two critical factors often underestimated are the complexity of supporting a reliable, scalable IDP long-term and the substantial opportunity cost of engineering resources spent building the platform versus building products. Companies also often need to pay more attention to the advantages of purpose-built solutions from third-party vendors compared to DIY options.