You Picked the Vendor for Price. Now They Set the Limits.

A SaaS company closes the year with better margins than expected. The reason: they picked the cheapest language model by token cost, integrated everything through the provider's proprietary SDK, and shipped. Eighteen months later, that model starts underperforming on more complex use cases. The team tries to migrate. They find that conversation context is stored in a provider-specific format, that their embeddings — numerical representations of text meaning, used for search and memory — were generated through the same API, and that the SDK wraps abstractions that simply don't exist anywhere else. Migrating means rewriting the core of the product.

This isn't an edge case. It's the pattern.

What looks like a technical decision is a strategic one

When the engineering team asks "which SDK should we use?", it sounds like an infrastructure choice. It isn't. It's a bet on who controls your product's capabilities two years from now.

Three architectural decisions carry most of the dependency risk:

• Which SDK or framework to use. Provider-specific SDKs often expose proprietary features that don't exist in open alternatives. Convenient early on, costly when you want to move.
• How and where context is stored. Context is the history and information a model uses to respond coherently. If it lives in a format or database tied to the provider, leaving means losing the product's memory.
• Where embeddings are generated. Embeddings from one model aren't directly compatible with another. Switching providers can invalidate the entire vector database powering your search, recommendations, and long-term memory features.

Each of these choices, on its own, seems reasonable. Together, they form a chain.

Why exit costs grow invisibly

The problem doesn't show up in the first quarter. It compounds quietly as the company scales.

Early on, the product has ten features using the model. Over time, it grows to fifty. Each new feature inherits the same architectural patterns as the ones before it. By the time the company wants to negotiate pricing, test a competing model, or add a capability the current provider doesn't support, the exit cost is no longer technical — it's strategic. Switching means pausing the roadmap for months, rewriting business logic, and in many cases temporarily degrading user experience.

The provider didn't do anything wrong. They simply became indispensable while no one was paying attention.

How to assess your dependency level today

There's a simple question that reveals a lot: if your primary LLM provider raised prices by 40% tomorrow, what would you do?

If the honest answer is "we'd pay it," you already have your diagnosis. But there are more precise ways to map the risk before it becomes real cost:

• Partial substitution test. Pick a non-critical feature and try running it with an alternative model without changing the architecture. If it can't be done in under a week, the dependency is already structural.
• Proprietary surface inventory. List how many API calls, response types, and data formats in your product only exist in your current provider's documentation. The longer the list, the heavier the anchor.
• Embedding portability cost. Estimate the time and cost of regenerating your entire vector database with a different model. In products with years of data, this can be the most expensive barrier of all.

It's not about switching providers. It's about having the option.

The right strategy isn't necessarily to run multiple providers simultaneously — that adds operational complexity without immediate benefit. The strategy is to build with enough portability that the option exists when you need it.

In practice, that means a few deliberate choices from the start:

• Prefer provider-agnostic orchestration frameworks over proprietary SDKs when the functionality is equivalent.
• Store context and conversation history in open formats, independent of the provider.
• Generate embeddings with models that have real market alternatives, or when feasible, with models running on your own infrastructure.
• Maintain internal documentation of which product features depend on capabilities exclusive to a specific vendor.

None of these choices are free. They cost a bit more time upfront. What they prevent is walking into a strategic planning meeting and discovering that your technical architecture already made the decision for you.

One thing to take from this

Before the next development sprint or the next contract renewal with your LLM provider, ask the team one question: which parts of our product only work with this specific vendor?

If no one can answer clearly, that's the first problem to solve. Not because the answer needs to be "none" — reasonable dependencies exist and can be acceptable. But because a company that doesn't know its own dependencies isn't making strategic decisions. It's being carried by them.