MODULE 8 · LESSON 1
Free — no login requiredSign in to track progress, save quiz attempts and enrol in the full course.
Sign in to track progress / enrolProvider Concentration and Dependency
Dependency is not only commercial
The obvious risk is price. The less obvious ones matter more:
Most teams assess only the first and last rows. The middle ones are more likely and are the ones that actually disrupt roadmaps.
Behavioural dependency is the most distinctive of these and was covered in module 3: your product's behaviour can change without you deploying anything.
Strategic dependency deserves a moment. If your product is a thin layer over a provider's model, and that provider moves up the stack into your category, you are competing with your own supplier — who knows your usage patterns and has a structural cost advantage. This is a real dynamic in this market, and the defence is not technical: it is to own something the provider does not, which is usually your customers' data, workflow integration and domain-specific evaluation.
Concentration across the stack
Assess it layer by layer, because concentration compounds:
- The model provider. How many realistic alternatives exist for your use case?
- The cloud. Frequently the same company, or a company with a large investment in the model provider.
- The accelerator supplier. Concentrated, upstream of everyone.
- The data centre and power. Regionally concentrated.
The compounding matters. A team believing it has diversified by using two model providers may find both run on the same cloud in the same region on the same accelerator supply. Correlated dependencies are not diversification, and mapping them takes an hour.
Portability without paying for it
Full multi-provider redundancy is expensive and usually unjustified for an early product. What is nearly free is preserving the option:
Abstract the provider behind your own interface. One place in your code that talks to a model. Not an elaborate framework — an internal boundary, so a swap is one implementation rather than a hundred call sites.
Keep prompts portable. Avoid depending on one provider's quirks where a generic formulation works as well. Where you must use provider-specific features, isolate them.
Make evaluation provider-agnostic. Your suite from module 3 should be runnable against any backend. This is the single most valuable portability investment, because it converts "could we switch?" from a guess into a measurement you can perform in an afternoon.
Keep your data yours. Embeddings, corrections, evaluation cases and fine-tuning datasets in your own storage in a portable format. Module 5 of the managers course makes the contractual version of this argument; here it is an architectural one.
Together these cost little during normal development and mean a forced migration is weeks rather than quarters.
When a second provider is worth it
Actively running two providers costs real money — dual evaluation, dual monitoring, dual contracts, quality differences to reconcile. Justified when:
- Availability requirements exceed what one provider offers, and you have quantified what an outage costs you.
- A market or customer will not accept your primary provider, which is the module 6 sovereignty case.
- Capacity constraints are already binding at peak.
- You are large enough that provider pricing leverage matters, and a credible alternative changes your negotiating position.
For most products the correct answer is one provider, an abstraction layer, a provider-agnostic evaluation suite, and a tested understanding of how long a switch would take. Know your migration time, even if you never use it — it converts an unbounded anxiety into a number you can plan against.
An exercise worth an hour with your technical lead. List every external dependency the product cannot function without, and for each answer four questions: what happens immediately if it disappears, how long could we survive, what is the alternative, and how long would switching take?
A typical first pass:
| Dependency | If it stops | Survivable for | Alternative | Switch time | |---|---|---|---|---| | Model API | Core feature unavailable | Hours | A second provider, untested | Unknown | | Vector database | Retrieval fails; answers ungrounded | Hours | Self-hosted alternative | Weeks | | Cloud region | Everything down | Minutes | Another region, no data there | Days | | Embedding model | New content cannot be indexed | Days | Another model, but the index must be rebuilt | Weeks | | Auth provider | Nobody can log in | Minutes | — | Unknown |
Three things this reliably surfaces.
"Unknown" is the real finding. Any row where switch time is unknown is an unbounded risk, and turning it into a number is often a day's work — running your evaluation suite against an alternative provider, or reading the migration documentation properly.
The embedding model row is the one teams miss. Changing embedding models means re-embedding your entire corpus, because vectors from different models are not comparable. For a large index that is a significant, slow and costly operation. It makes the embedding model a stickier dependency than the generation model, which is the reverse of most teams' intuition.
Correlation shows up when you add a column for where each runs. Two providers on the same cloud in the same region is a single point of failure wearing two names.
The output is not a plan to remove every dependency — that is neither possible nor sensible. It is knowing which ones would hurt, for how long, and which "unknown" is worth converting into a number this quarter.
Why is the embedding model often a stickier dependency than the generation model?
The seven dependencies
Click to flipCommercial, roadmap, behavioural, capacity, reputational and regulatory, availability, and strategic. Most teams assess only price and outages.
Click to flip backDependency runs deeper than price: roadmap, behaviour, capacity, regulation, availability and competitive position all sit on your provider. Map concentration across the whole stack, because two providers on one cloud is not diversification. Buy the option to move cheaply — an internal interface, portable prompts, a provider-agnostic evaluation suite, and your data in your own storage — and convert every "unknown" migration time into a number, starting with the embedding model, which is stickier than most teams realise.