Could your product cope if you had to change AI providers?

If AI is part of the service you sell, a decision by its provider can become a decision you have to explain to your customers. A price change might affect your margin. A limit might affect how much work you can process. Losing access might interrupt a feature people depend on.

In my LinkedIn post on AI supplier dependence, I suggested asking your developer how difficult it would be to switch providers. It is a useful opening question, but it needs a longer conversation behind it.

Look at the job the AI is doing

Imagine a product that turns customer emails into draft support replies. To evaluate a replacement model, you need to know what makes a reply acceptable.

Perhaps it must use the correct refund policy, recognise when an account needs human attention and avoid promising services you do not offer. A reply that sounds polished can still fail those requirements.

Before comparing suppliers, write down the tasks the feature performs and how you will judge the result. Anthropic's evaluation guidance recommends specific, measurable criteria connected to the application's purpose. That principle is useful whichever provider you are considering.

For the fictional support product, I would prepare examples of common requests alongside difficult ones: an ambiguous complaint, missing account information, a refund outside the usual period. Use appropriately prepared test data rather than sending customer information to an additional supplier without reviewing that choice.

Ask which parts of the product depend on the provider

The obvious dependency is the request that sends information to the model. There may be others: uploaded documents, stored conversation history, provider-specific tools or assumptions about how the response is formatted.

Ask your developer to map those dependencies and explain what can be reused. Which prompts and examples does your team control? What information would have to be moved? Which behaviours would need to be checked again?

Keeping provider-specific code in a clearly defined part of the application can make changes easier to manage. It does not make models interchangeable. A replacement can require different instructions or produce different results, so the work includes evaluation as well as integration.

You want an estimate that separates those tasks. “The connection takes a day to change” tells you little about when you could safely offer the replacement to customers.

Decide what customers should experience during a failure

For the support product, a temporary failure might mean staff write replies themselves while the rest of the service continues. Another product might need to queue work and tell customers when to expect a result.

Ask what your current product does when the provider is slow or unavailable. Does the customer see a useful explanation? Can work be retried without duplicating an action? Can someone in your team see what is waiting?

The right response depends on the promise you have made. Automatically switching models is only helpful if the alternative has been checked for the task and the way it handles your data is acceptable.

Make a proportionate decision

An early prototype may not justify building a second integration. You can still record the dependency, keep your instructions and evaluation examples accessible, and decide what would trigger further work.

For a live product, that trigger could be an agreed cost level, repeated interruptions or a customer requirement the current provider cannot meet. Writing it down gives you a reason to act before the decision becomes urgent.

JiNi helps founders review architecture and understand technical choices in existing products. If you are unsure how dependent your product is on its AI supplier, contact us to discuss the feature. We can help examine the dependencies and the changes worth considering for your stage of growth.