The Platform Dependency Trap: When Efficiency Becomes Lock‑In

Buy versus build is one of those questions that sounds strategic and usually arrives too late.

By the time most teams ask it, they have already made the more important decision. They have decided where capability will live.

That is the real issue.

A company can buy software and still retain strong internal capability. It can build on platforms without becoming captive to them. It can use agencies, composable stacks, SaaS layers, cloud services, and AI providers without losing control of its digital estate. The trap appears when efficiency is pursued by steadily removing the internal ability to understand, challenge, change, migrate, or replace the systems the company depends on.

Then the platform is no longer a tool. It becomes a strategic dependency.

This is happening in several layers at once. Businesses outsource marketing sites into agency‑owned workflows. Product teams lean on closed SaaS platforms without an exit path. Editorial teams adopt CMS features they cannot later migrate cleanly. Engineering teams push more business logic into vendor APIs, integration hubs, and cloud‑specific managed services. AI tooling adds another dependency layer above that. Each local step can make sense. Together they can leave the company faster in the short term and weaker in the medium term.

Buy versus Build is the Wrong Level of Abstraction

The conventional framing assumes the choice is between internal effort and external software.

That is too simple. The harder and more useful question is which parts of the system the organisation must be able to reason about, evolve, and replace without begging for access to its own future.

The Government Digital Service makes this point directly in its guidance on avoiding technical lock‑in. The problem is not external software in itself. The problem is making choices that leave the organisation overly dependent on one supplier, one format, one proprietary service, or one hard‑to‑switch integration path (GDS guidance on managing technical lock‑in).

That is exactly the risk many transformation programmes misprice. They treat externalisation as if it automatically reduces complexity. Often it reduces visible complexity for one team whilst increasing dependency complexity for the business as a whole.

Capability Ownership Matters More than Code Ownership

A company can own the code and still not own the capability. It can also use third‑party platforms and retain meaningful control.

Capability ownership means the organisation still knows:

• how the system fits together
• which business rules matter most
• how data flows through the stack
• what assumptions exist between services
• what it would take to migrate or replace key parts
• which suppliers can be challenged because the customer understands the terrain

That distinction is especially important in CMS, e‑commerce, and multi‑site platform work. A business may adopt a headless CMS, a composable commerce layer, or a multi‑tenant platform and believe it has made the platform easier to change. Sometimes it has. Sometimes it has merely shifted dependence from one monolith to several specialist providers with fewer in‑house people who can explain the whole picture.

That is why the practical architecture work in Building a Headless CMS‑Powered Site with Next.js is still relevant (Building a Headless CMS‑Powered Site with Next.js) and why the broader trade‑offs in All About Headless CMSes still matter (All About Headless CMSes). The architecture question is not whether the stack sounds modern. It is whether the organisation understands the consequences of the stack it now relies on.

Vendor Concentration is Not a Theoretical Risk

Platform dependency gets more serious when the surrounding market is concentrated.

Cloud is the clearest example. Ofcom's market study described public cloud infrastructure as a critical input across the UK economy and identified concerns around switching, interoperability, and the dominance of hyperscalers (Ofcom's cloud services work). The CMA's later cloud services market investigation concluded that competition concerns in these markets were likely to be leading to higher costs, less choice, less innovation, and lower quality for UK customers (the CMA's cloud services market investigation).

Ofcom's decision to refer the market onward to the CMA is a useful reminder that these concerns were not theoretical background noise. Regulators considered the switching and concentration issues serious enough to escalate formally (Ofcom's cloud services work).

That does not mean firms should avoid hyperscalers. It means they should stop pretending that deep dependence on them is a neutral implementation detail.

Concentration Changes Negotiation

When a market is concentrated, "just move later" becomes an expensive fantasy.

If exit fees are punitive, if switching requires architectural redesign, if operational staff know only the incumbent tooling, or if procurement has no realistic alternative route, the supplier has the stronger negotiating position and the customer knows it. The dependency is technical, commercial, and organisational at once.

Concentration Also Changes Resilience

When many systems rest on the same cloud, identity, data, or AI providers, the business may have fewer independent failure domains than its diagrams suggest. The dependency problem is not only price. It is common‑mode risk.

AI Vendors are Becoming Part of the Same Dependency Story

This is where the platform question joins the current AI conversation.

Many firms are adding AI capability by consuming vendor features rather than building model infrastructure themselves. That is rational. But it also means AI dependency often arrives bundled inside existing platform dependency. A cloud provider becomes the model route. A productivity suite becomes the assistant route. A SaaS vendor becomes the workflow route. An agency becomes the implementation route.

The CMA's foundation model work is important here because it highlights how control over critical inputs, routes to market, and partnership structures can shape competition and dependency across the AI value chain (the CMA's foundation model update paper and the CMA's competition concerns update).

The business may think it is diversifying because different teams are using different tools. In practice, many of those tools may still depend on the same small set of underlying providers.

Agency Dependency is Still Dependency

Firms often recognise vendor dependency more quickly than agency dependency, even though the two can merge.

An agency‑managed platform can be productive and well run. It can also become a trap if the client cannot easily reconstruct how the system works, how the content model is shaped, where integration logic sits, what deployment assumptions exist, or how to transfer control cleanly.

This shows up most painfully during migrations. A business decides it needs to change CMS, rework its multi‑site estate, or redesign its content workflow. Suddenly it discovers that the real asset is not the code repository. It is the operational understanding held by a supplier, a handful of freelancers, or a set of undocumented conventions.

That is why How to De‑Risk a CMS Migration Before the Real Migration Starts focuses so much on inventory, dependency mapping, content behaviour, and operational reality before the actual migration work begins (How to De‑Risk a CMS Migration Before the Real Migration Starts). A migration is rarely blocked by a lack of tools. It is blocked by a lack of retained understanding.

CMS and Composable Stacks Can Still Produce Lock‑In

Composable architecture is often sold as the antidote to lock‑in. Sometimes it is. Sometimes it simply distributes the lock‑in across more contracts and more integration points.

This happens when:

• content models are deeply shaped around one vendor's assumptions
• preview, publishing, and search flows depend on proprietary behaviour
• integration glue becomes as hard to migrate as the original platform
• nobody maintains a current view of the end‑to‑end estate
• internal teams understand the front‑end shell but not the content or operational backbone

Multi‑tenant estates add another layer. Shared platform capability can be a major strength when it improves consistency, cost efficiency, and governance. It becomes risky when the business cannot confidently separate what is shared by design from what is entangled by accident. The patterns in Building a Multi‑Tenant Application with Next.js are useful precisely because platform reuse only works well when the boundaries are clear (Building a Multi‑Tenant Application with Next.js).

The lesson is not that composable is bad. It is that composable does not excuse you from understanding the composition.

Exit Paths are Part of Architecture

One of the clearest signs of unhealthy dependency is that nobody can describe the exit path without hand‑waving.

Healthy platform choices do not require immediate migration plans. They do require that someone can explain:

• what data can be exported
• what workflows depend on proprietary features
• what the likely migration sequence would be
• what costs are likely to be one‑off versus recurring
• what operational retraining would be needed
• which dependencies are hard and which are soft

This is not abstract. The European Data Act explicitly aims to improve fairness and switching conditions in data and cloud‑related contexts, including interoperability and easier movement between processing services (the European Data Act).

The fact that regulators now have to intervene around switching and interoperability is itself a signal. Exit is not automatically cheap just because a contract says data is portable.

Data Gravity and Workflow Gravity Harden Dependence

The reason platform lock‑in becomes so stubborn is not only contract structure. It is gravity.

Data gravity appears when content, analytics, operational history, permissions, and business rules accumulate inside one platform faster than the organisation documents how to reconstruct them elsewhere. Workflow gravity appears when teams adapt their habits, approvals, publishing routines, campaign processes, and support playbooks around the quirks of the incumbent system until those quirks stop feeling optional. At that point, even a technically possible migration can become socially and operationally expensive.

This is why exit planning cannot be reduced to export functionality. A business may be able to export records and still be unable to move smoothly because the harder dependency sits in process memory rather than file format alone.

Negotiation Power Only Exists If Alternatives Stay Legible

The other consequence of capability erosion is commercial.

Suppliers negotiate differently when they believe the customer understands the estate well enough to move, re‑scope, or separate layers over time. They negotiate differently again when the customer clearly cannot. That is why internal capability is not only a technical asset. It is a bargaining asset. The clearer your own alternative paths are, the more credible your negotiating position remains even if you never use it.

What Healthy Platform Ownership Looks Like

The answer is not maximal insourcing. It is deliberate capability retention.

1. Keep Architectural Understanding in‑House

The organisation should be able to explain the core estate without relying on a supplier to narrate it back. That includes data flow, content models, identity boundaries, integration points, failure modes, and migration risks.

2. Own the Commercial Logic

Pricing, entitlement rules, customer states, reporting assumptions, and market‑specific behaviour should not disappear into opaque vendor configuration where the business cannot reason about them clearly.

3. Maintain Credible Exit Options

An exit option does not need to be cheap today. It does need to be thinkable. If the route out is unknowable, the negotiating power already belongs elsewhere.

4. Avoid Concentration by Accident

Review where cloud, CMS, analytics, identity, AI, and agency dependencies overlap. Different logos do not always mean different control points.

5. Treat Migration Readiness as a Standing Capability

The firms that handle platform change best are usually the ones that behave as if migration is always a future possibility, not an emergency event. That means current documentation, deliberate boundaries, stable naming, and clear ownership.

A Better Platform Decision Framework

Before committing to a new platform, service, or agency‑managed estate, leadership should ask a sharper set of questions.

• Which capability are we actually buying?
• Which capability are we giving up?
• If this supplier doubled price or changed terms, what would our options be?
• If we had to move in two years, what would hurt most?
• Do we understand our own data and workflow model well enough to migrate?
• Are we choosing speed, or are we choosing dependence and calling it speed?

That last question is the awkward one. Sometimes dependence is a rational trade. The mistake is pretending it is not a trade at all.

Conclusion

Platforms can absolutely make teams faster. Agencies can absolutely accelerate delivery. CMS layers, cloud services, composable tools, and AI providers can all create useful speed and choice.

But speed and optionality are not the same thing as control.

The platform dependency trap appears when organisations optimise for short‑term delivery by cutting away the very capability that lets them understand, negotiate, adapt, and eventually change their own estate. At that point, efficiency starts to look a lot like managed dependence.

The healthier model is not to refuse platforms. It is to use them without forgetting that digital transformation is supposed to leave the business more capable than before, not merely more outsourced.