The IDP That Was Built Too Early
A platform engineer at a Series B startup told me about the IDP her team built in 2023 when the engineering organization was thirty people. The platform took six months to build. It abstracted Kubernetes deployment, CI/CD, observability, and developer tooling. The pitch decks looked great. The actual adoption was poor.
Engineering teams at thirty people did not need an abstraction layer. They needed direct access to the underlying tools. The IDP added friction without adding value because the underlying complexity was not yet large enough to warrant abstraction. By the time the organization grew to a hundred engineers, the IDP had been quietly deprecated and the team had rebuilt against the underlying tools directly.
She told me the experience taught her that IDPs solve specific problems at specific scales. Below the threshold, they create problems they were meant to solve. Above the threshold, they pay back substantially. The threshold is real and worth identifying before committing engineering capacity.
The IDP pattern is genuinely useful for engineering organizations of certain sizes. It is also misapplied at organizations that do not yet need it or that need different solutions. Knowing when to start and how to sequence the buildout matters.
The Prior Authorization AI Trap
What the 16x denial rate finding means for engineering teams building PA automation.
When the IDP Threshold Hits
The IDP threshold is not a hard number. It depends on engineering complexity more than headcount alone. Three signals usually indicate the threshold has arrived.
The first signal is cognitive load on individual engineers. Engineering teams spend substantial time on infrastructure concerns rather than on product. Onboarding new engineers takes weeks because the production stack is complex. Senior engineers operate as platform support rather than as feature builders.
The second signal is inconsistency across teams. Different product teams have built different patterns for the same problems. Deployment, observability, secrets management, environment provisioning all vary. The variance produces maintenance overhead and security gaps.
The third signal is platform team backlog. The team responsible for shared infrastructure cannot keep up with product team requests. Engineering velocity slows as platform tickets queue.
When two or three of these signals are present, the IDP threshold has arrived. The organization usually has 75 to 200 engineers at this point. The exact number varies based on workload complexity and existing infrastructure investment.
Below the threshold, the signals are weaker or absent. Engineers can operate the underlying tools without overhead. Teams converge on patterns naturally. Platform team backlog is manageable. Building an IDP at this scale solves problems that are not yet problems.
Above the threshold, the signals intensify. The cost of operating without an IDP grows with organization size. Building an IDP at this scale pays back through addressed signals.
The Buildout Phases That Work
IDP buildouts that succeed follow recognizable phases. The phases are not strictly sequential; they overlap. The sequence matters because earlier phases build the trust and capability that later phases depend on.
The first phase is golden path documentation. The platform team documents the recommended way to deploy a service, the recommended observability setup, the recommended secrets management. The documentation is opinionated and supported. Product teams can follow the golden path or deviate; deviations come with the trade-off of less support.
The first phase often gets skipped because documentation feels less substantial than tooling. Skipping it produces IDPs that do not match how product teams actually want to work. The documentation surfaces the requirements that the tooling has to address.
The second phase is shared tooling for the golden path. The platform team provides templates, libraries, CI patterns, and shared services that implement the golden path. Product teams adopt the tooling for new services. Existing services migrate over time.
The second phase establishes platform team credibility. The shared tooling has to work well enough that product teams actually use it. Tooling that produces friction gets bypassed regardless of platform mandates.
The third phase is self-service interfaces over the shared tooling. The platform team builds web UIs, CLIs, and APIs that let product teams provision resources, deploy services, and manage their applications without platform team intervention. This phase is what most people mean by IDP.
The third phase pays back the first two. The self-service interfaces work because the underlying tooling works because the golden path was documented and refined.
The fourth phase is platform engineering as a product discipline. The platform team treats developer experience as a product. Product teams are customers. Feedback flows continuously. The platform evolves based on what product teams actually need.
The fourth phase is what distinguishes mature platform organizations from organizations that built an IDP and stopped. The platform is not a finished product; it is a continuously evolving capability.
What Goes Wrong in IDP Buildouts
Three patterns of IDP failure are common enough to call out.
The first pattern is building too much abstraction. The IDP tries to hide all underlying complexity. Product teams that need to debug or customize cannot reach the underlying tools through the abstraction. The abstraction becomes a barrier rather than an aid. The successful IDPs typically expose underlying tools for advanced users while providing simplified interfaces for common cases.
The second pattern is platform-team-first design. The IDP gets built based on what the platform team thinks product teams need. The platform team's mental model does not match the product teams' actual workflows. The IDP gets adopted reluctantly. Product teams build workarounds.
Successful IDPs are usually built with continuous product team input. Embedded engineers from product teams. User research that surfaces what teams actually do. Iteration based on adoption metrics.
The third pattern is over-investing in the IDP itself. The platform team builds elaborate IDP capabilities without addressing the underlying infrastructure quality. The IDP becomes a polished front-end for a brittle back-end. The brittleness becomes visible as soon as product teams hit edge cases.
Successful IDPs are usually built on solid underlying infrastructure first. The IDP is the user experience over the infrastructure, not a replacement for the infrastructure.
Build Versus Buy
The IDP build-versus-buy decision has shifted in 2024 and 2025 as commercial platforms (Backstage, Port, Cortex, Humanitec, Mia-Platform) have matured.
Building from scratch made sense in 2020 because credible commercial options did not exist. The leaders in the space (Spotify with Backstage, Netflix with internal platforms) built their own because they had to.
Building from scratch in 2026 makes sense for organizations with very specific requirements that commercial platforms do not address. Most organizations do not have these requirements. Most organizations get further faster by adopting a commercial platform and customizing.
The commercial platforms differ in approach. Backstage is open-source and highly customizable. Port focuses on developer self-service and integration breadth. Cortex emphasizes service ownership and quality scorecards. Humanitec and Mia-Platform target different aspects of platform engineering.
The choice depends on the organization's specific needs. Most organizations benefit from evaluating two or three options before committing.
What This Costs
Building an IDP from scratch typically requires a dedicated platform team of five to ten engineers for one to two years for initial maturity, plus ongoing capacity for continued development. The investment is substantial.
Buying a commercial platform reduces the initial investment to two to four engineers for setup and customization. Ongoing investment is similar to building because the platform still has to be operated and evolved.
For mid-market organizations crossing the IDP threshold, buy usually wins on cost-benefit. For very large organizations with unique requirements, build sometimes wins. The trajectory through 2026 has been more organizations choosing buy as commercial platforms have improved.
Clinical AI Hallucination
Why 91.8% of clinicians have encountered medical AI hallucinations, the three structural failure modes.
What Logiciel Does Here
Logiciel works with engineering leadership evaluating IDP investment or rationalizing existing platform efforts that have not produced expected returns. The work is typically structured around threshold assessment, buy-versus-build decision, and buildout phasing appropriate to the organization's specific situation.
The DevOps + Cloud Delivery Pipeline framework covers the broader pipeline considerations that IDPs sit within. The Cloud-Native Refactoring framework covers the underlying infrastructure modernization that often runs in parallel to IDP buildout.
A 30-minute working session is enough to assess whether your organization has hit the IDP threshold and what buildout approach fits.
Frequently Asked Questions
How do I know if my organization is ready for an IDP?
Through the three signals (cognitive load, inconsistency, platform team backlog). If two or three signals are clearly present, the threshold has arrived. If one or none are present, the IDP investment is probably premature.
What is the right team size for the platform function?
At threshold, three to five engineers. At maturity, eight to fifteen engineers depending on organization scale. The team grows with organizational complexity rather than with engineering headcount linearly.
How do I avoid the abstraction trap?
By exposing underlying tools alongside abstractions. Product teams that need direct access can reach it. Product teams that benefit from abstraction get the simplified interface. Pure abstraction without escape hatches usually fails.
What is the role of platform engineering in security?
Platform engineering owns the secure defaults that product teams inherit. Secrets management, network policies, identity integration, audit logging. The IDP is a primary mechanism for enforcing security baselines without imposing review overhead on every product change.
How does AI integration affect IDP design?
AI workloads add specific requirements (GPU access, model serving infrastructure, AI observability) that traditional IDPs may not handle. Modern IDPs increasingly include AI workload templates and patterns. Organizations with significant AI workloads should evaluate platforms for AI fit specifically. Sources: - Backstage documentation, 2024 - Gartner, "Platform Engineering Hype Cycle 2024"
