Internal Developer Platform (IDP) Concentration Risks

1. Introduction

An Internal Developer Platform (IDP) is a technology platform used within an organisation to standardise and automate software development and deployment. It may provide developers with a common interface for:

cloud infrastructure;

computing resources;

databases;

APIs;

identity and authentication;

security tools;

CI/CD pipelines;

observability;

deployment environments;

AI and machine-learning services;

software repositories; and

compliance controls.

IDPs are generally intended to reduce complexity, improve developer productivity, and standardise infrastructure. However, from a competition-law perspective, excessive concentration around an IDP can create risks where the platform becomes an unavoidable technological bottleneck.

The key concern is that an IDP may evolve from an internal productivity tool into a strategic infrastructure layer controlling access to computing, applications, data, developers, and technological capabilities.

2. Meaning of IDP Concentration

IDP concentration exists when a substantial proportion of an organisation's development activity becomes dependent upon:

one internal platform;

one platform team;

one technology stack;

one cloud environment;

one API architecture;

one identity system;

one deployment framework; or

one group of infrastructure providers.

The competition issue becomes more significant where the IDP is used across multiple legally or economically distinct businesses.

For example:

Cloud infrastructure → internal developer platform → applications → AI services → customer-facing platforms.

If the same technological layer controls all these downstream activities, the IDP can become a bottleneck facility.

3. IDP as a Competition-Relevant Infrastructure Layer

Traditional competition law often examines:

manufacturer → wholesaler → retailer → consumer.

Digital markets increasingly contain another layer:

infrastructure → developer platform → applications → users.

The IDP sits between infrastructure and software development.

It can therefore determine:

which cloud services developers can access;

which APIs can be used;

which programming environments are supported;

which security standards apply;

which applications can be deployed;

which vendors can integrate;

and how easily developers can switch technology.

This creates potential vertical leverage.

4. Why Concentration Can Become a Competition Problem

Concentration itself is not unlawful.

A company may legitimately adopt one internal platform because it is:

cheaper;

safer;

easier to manage;

more reliable;

more secure; or

technologically superior.

The competition concern arises where concentration produces or reinforces:

A. Dependency

Developers become unable to operate effectively without the platform.

B. Switching costs

Migration to another platform requires substantial:

rewriting;

retraining;

data migration;

infrastructure redesign;

compliance re-certification.

C. Vendor lock-in

The IDP may embed one cloud provider, database, AI model, or API provider.

D. Foreclosure

Alternative technology providers may be denied access to the organisation's development ecosystem.

E. Self-preferencing

An IDP controlled by a dominant infrastructure provider could favour affiliated products.

5. IDP Concentration and Article 102 TFEU

Where the IDP provider is dominant in a relevant market, Article 102 TFEU may become relevant.

Potential theories include:

refusal to supply;

discriminatory access;

tying;

bundling;

self-preferencing;

margin squeeze;

exclusionary interoperability restrictions.

The crucial question is whether the IDP constitutes an important gateway through which rivals must pass.

For example:

dominant cloud provider → IDP → developers → downstream applications.

If the cloud provider makes its own services interoperable with the IDP while imposing technical restrictions on rival services, the platform can become a mechanism for downstream foreclosure.

6. IDP Concentration Under German Competition Law

German competition law is particularly relevant because the GWB provides tools for addressing powerful digital ecosystems.

Section 19 GWB addresses abusive conduct by dominant undertakings.

Section 19a GWB provides an additional framework for undertakings of paramount significance across markets.

This is highly relevant where an undertaking controls several interconnected digital layers.

An IDP may become strategically important when it connects:

cloud infrastructure + developer tools + AI + operating systems + APIs + enterprise software.

The competition analysis may therefore extend beyond a narrowly defined developer-tool market and examine cross-market ecosystem power.

7. IDP Concentration and Essential-Facility Logic

An IDP may sometimes resemble an essential facility, although the strict legal test for an essential facility must not be assumed automatically.

The relevant questions include:

Is access indispensable?

Can developers reasonably reproduce the platform elsewhere?

Is duplication economically feasible?

Does denial of access eliminate effective competition?

Is there an objective justification for the restriction?

Where an IDP becomes indispensable to downstream competition, access conditions can become an important antitrust issue.

8. Six Important Case Laws

1. Bronner v Mediaprint, Case C-7/97

The Court of Justice established the stringent framework traditionally associated with refusal-to-supply and essential-facility situations.

The Court emphasised the exceptional nature of compelling a dominant undertaking to provide access to an asset.

Relevance to IDPs

Suppose a dominant technology provider controls an IDP through which developers must deploy applications.

The question would be whether access is genuinely indispensable and whether effective competition would otherwise be eliminated.

The case therefore provides the starting point for analysing:

IDP access + indispensability + refusal to provide access.

9. Microsoft Corp. v Commission, Case T-201/04

This is one of the most important cases for digital infrastructure and interoperability.

The European Commission found that Microsoft abused its dominant position through restrictions involving interoperability information.

The General Court upheld the essential aspects of the Commission's reasoning.

Relevance to IDPs

An IDP depends heavily upon interoperability.

Restrictions concerning:

APIs;

protocols;

authentication;

data formats;

deployment systems;

can make competing services difficult to integrate.

Thus, interoperability can become a competitive resource.

10. IMS Health GmbH & Co. OHG v NDC Health, Joined Cases C-418/01

The Court of Justice examined refusal to license intellectual property and the circumstances under which access to an indispensable structure may become a competition-law obligation.

IDP relevance

A highly concentrated IDP may contain:

proprietary APIs;

unique deployment interfaces;

exclusive datasets;

infrastructure integrations.

If developers cannot realistically compete without those resources, the IMS Health principles may become relevant.

However, the stringent conditions for compulsory access remain important.

11. Commercial Solvents Corp. v Commission, Joined Cases 6/73 and 7/73

This classic EU case concerned a dominant undertaking's refusal to supply an input to a downstream competitor.

The case established an important principle against using upstream dominance to eliminate competition downstream.

Application to IDPs

Consider:

dominant infrastructure provider → IDP → downstream software applications.

If the infrastructure provider supplies its own downstream business while denying essential infrastructure access to competitors, the conduct could raise analogous foreclosure concerns.

12. Slovak Telekom a.s. v Commission, Case C-165/19 P

This case concerns exclusionary conduct involving access to telecommunications infrastructure and the relationship between refusal-to-deal theories and Article 102.

Relevance

Modern IDPs increasingly operate as infrastructure gateways.

A dominant provider might control:

network access;

cloud resources;

developer tooling;

authentication;

deployment systems.

The case demonstrates the importance of examining the precise legal theory supporting an access obligation rather than assuming that every refusal is automatically abusive.

13. Google Shopping, Case C-48/22 P

The Google Shopping litigation is important for understanding self-preferencing and the use of dominance in one digital layer to favour services in another.

The case concerned Google's conduct in relation to comparison-shopping services.

Relevance to IDPs

An IDP provider might theoretically favour its own:

databases;

cloud services;

AI models;

security tools;

monitoring systems;

API services.

If competing services are technically disadvantaged while affiliated products receive preferential treatment, the IDP may become an instrument of vertical foreclosure.

14. Google Android, Case T-604/18

The Android litigation concerned Google's contractual arrangements and the relationship between operating-system dominance and adjacent digital markets.

IDP relevance

The case illustrates how control over one digital layer can be used to influence neighbouring markets.

An IDP can similarly become a gateway between:

infrastructure → developer → application → user.

The broader lesson is that competition analysis cannot always treat each technological layer as completely independent.

15. The IDP as a Bottleneck

A particularly important concept is bottleneck control.

An IDP can control access to:

computing resources;

deployment environments;

authentication;

security;

APIs;

databases;

AI models;

monitoring;

application distribution.

If developers cannot reasonably bypass the platform, the IDP becomes a bottleneck.

The competition problem is then:

control of infrastructure → control of developer choice → control of downstream competition.

16. Network Effects

Although an IDP is usually internal, network effects can develop indirectly.

More developers using the platform can create:

more internal documentation;

more reusable components;

more automation;

more integrations;

more institutional knowledge.

This creates a feedback loop:

more users → more integrations → greater platform value → higher switching costs → more users.

The result can be organisational network effects.

17. Switching Costs

One of the most important risks is technological switching cost.

Suppose a company standardises on an IDP supporting:

Cloud A;

Database A;

AI Model A;

Identity System A.

After several years, applications become deeply dependent on these services.

Moving to:

Cloud B;

Database B;

AI Model B;

could require substantial redevelopment.

Consequently, the IDP may create path dependency.

18. Data Lock-In

An IDP may centralise:

developer activity;

application telemetry;

security logs;

deployment information;

performance data;

customer usage;

infrastructure metrics.

Concentration of this data can provide the platform operator with informational advantages.

A dominant technology provider could potentially use aggregated information to identify:

emerging competitors;

successful applications;

customer switching;

technology trends.

This creates a form of informational foreclosure.

19. AI and IDP Concentration

AI substantially increases the significance of IDPs.

Modern developer platforms may integrate:

foundation models;

coding assistants;

AI agents;

vector databases;

inference infrastructure;

model-routing systems.

If one IDP becomes the default gateway to AI capabilities, it may determine:

which models developers can access;

which models receive preferential treatment;

pricing;

compute allocation;

API availability.

This can create an AI infrastructure bottleneck.

20. Tying and Bundling

An IDP provider could theoretically bundle several products:

IDP + cloud + database + identity + AI model + cybersecurity.

Bundling is not automatically unlawful.

The competition question is whether the arrangement:

forecloses competitors;

forces customers to purchase additional products;

raises rivals' costs;

reinforces dominance;

prevents multi-homing.

The digital context makes this particularly significant because technological integration can make separate products appear to function as a single technical package.

21. Self-Preferencing

Suppose an IDP permits developers to choose among:

several AI models;

several cloud providers;

several databases.

If the platform owner secretly or structurally gives its affiliated services:

faster access;

better APIs;

lower latency;

superior documentation;

preferential pricing;

greater compute allocation,

competition concerns may arise.

This resembles the broader self-preferencing concerns examined in digital-platform litigation.

22. Interoperability

Interoperability is central to preventing excessive IDP concentration.

A competitive IDP ecosystem should ideally permit developers to integrate with multiple:

cloud providers;

databases;

AI models;

identity providers;

monitoring systems;

security tools.

Interoperability reduces:

switching costs + dependency + foreclosure.

Accordingly, technical standards can have direct competition-law implications.

23. Remedies

Where IDP concentration creates genuine competition concerns, possible remedies include:

Structural remedies

separation of infrastructure and downstream services;

divestiture;

independent platform governance.

Behavioural remedies

non-discrimination;

interoperability;

API access;

portability;

transparent pricing.

Technical remedies

open APIs;

standardised interfaces;

container portability;

multi-cloud compatibility;

model portability.

Governance remedies

independent compliance officers;

access committees;

information firewalls;

audit mechanisms.

24. Competition-Law Assessment Framework

A regulator examining IDP concentration should ask:

Step 1 — What is the relevant market?

Possible markets include:

developer platforms;

cloud infrastructure;

DevOps tools;

AI infrastructure;

enterprise software;

API management.

Step 2 — How concentrated is the platform?

Examine:

market share;

developer dependency;

switching rates;

alternative providers.

Step 3 — Is the IDP indispensable?

Determine whether viable alternatives exist.

Step 4 — What switching costs exist?

Assess:

technical;

contractual;

financial;

organisational;

data-related costs.

Step 5 — Is the platform vertically integrated?

Examine whether the provider also controls:

cloud;

AI;

databases;

operating systems;

applications.

Step 6 — Is there discriminatory conduct?

Compare treatment of affiliated and independent services.

Step 7 — Are rivals foreclosed?

Assess actual and potential competitive effects.

25. Key Case-Law Principles

26. Conclusion

Internal Developer Platforms can produce substantial efficiency benefits. They standardise infrastructure, improve security, accelerate deployment, and reduce technological complexity.

However, excessive concentration can transform an IDP from a productivity tool into a digital bottleneck.

The principal competition risks are:

developer dependency;

vendor lock-in;

high switching costs;

interoperability restrictions;

self-preferencing;

vertical foreclosure;

data concentration;

AI infrastructure control;

cross-market leveraging; and

ecosystem reinforcement.

The jurisprudence of Bronner, Microsoft, IMS Health, Commercial Solvents, Slovak Telekom, Google Shopping and Google Android demonstrates the principal legal foundations for analysing these risks.

The central competition-law proposition is therefore:

An Internal Developer Platform should not be considered problematic merely because it is highly concentrated. The competition concern arises when control over the developer infrastructure becomes sufficiently indispensable, difficult to bypass, or vertically integrated that the platform operator can use it to restrict interoperability, discriminate against rivals, leverage dominance into adjacent markets, or reinforce an ecosystem monopoly.

In the emerging AI economy, this issue is likely to become increasingly important because the IDP may become the principal gateway through which developers obtain access to compute, foundation models, data, APIs, security and deployment infrastructure.