Building a product on AI models you don't control

Most AI products today, including mine, stand on models that someone else trains, hosts and changes. Building an AI product on third-party models is the fastest way to ship something useful. It is also a quiet agreement to let another company move the floor under your feet whenever it likes.

I don't think that is a reason to avoid it. I think it is a reason to build with your eyes open. Here is how I think about it while building Bolo Media, which turns a product photo or a few lines of text into video ads with natural Gujarati and Hindi voices.

I am deliberately not naming the models or providers I use. They change, and this post is about the pattern, not the brand.

I have seen this movie before

I started my career as an Android developer in 2009. Android was young then, and the platform changed quickly. Things you built on one version needed rework on the next. Developers who had tied their app tightly to how the platform behaved that month felt it most.

AI models today feel similar, only faster. A model you depend on can be updated, renamed, re-priced or retired. The difference is that with a phone OS, you could at least read the release notes and plan. With a hosted model, the change can be subtle: the same prompt, the same input, and a slightly different output.

The lesson from those early Android years still holds for me: depend on the platform, but don't marry its quirks.

Building an AI product on third-party models: what can change

When you build an AI product on third-party models, these are the things outside your control. None of this is a complaint. It is just the job description.

• Behaviour. A model update can change tone, pronunciation, pacing or image style. For a product that promises natural Gujarati voice, a small change in how a word is spoken matters a lot.
• Price. Usage pricing can go up or down. Down is pleasant. Up can break your unit economics overnight.
• Availability. Hosted services go down, slow down or rate-limit you at the worst possible time.
• Policy. Terms of use, content rules and regional availability can shift.
• Existence. Models get deprecated. Sometimes with good notice, sometimes with less.

If your customer is a shop owner who wants an ad for Diwali, none of these are their problem. They only see whether the video arrived and whether it sounds right.

Design for replacement, not loyalty

The most useful rule I follow is simple: every model is a part, not the product.

Keep a thin layer between you and the model

The rest of my product should not know which model produced a voice or an image. It should ask for "a Gujarati voice-over for this script" and get one back. If a model has to be swapped, the change should stay in one place. This is ordinary software engineering, the kind I spent years practising long before AI. AI does not make it less true. It makes it more urgent.

Own your evaluation

You cannot rely on a provider's benchmark to tell you whether their model reads a Gujarati shop name correctly. The habit I believe in is a small, private set of test inputs that look like what real customers send, so a new model, or a new version of an old one, can be checked before it goes near a real order. A good test set is worth more than any single model.

Know your fallback before you need it

For each important step, I want to know what happens if the main option fails. Is there a second model that is good enough? Can the job wait and retry? Should the customer be told honestly that it will take longer? Deciding this calmly on a quiet day is much better than deciding it during an outage.

Where your real value lives

If the model is a part someone else can swap, then a fair question is: what is left that is yours?

For me, the answer is everything around the model:

• Understanding what a small business in Gujarat actually needs from an ad.
• Writing and checking scripts so they read naturally in Gujarati and Hindi.
• Handling the words, names and numbers that models get wrong.
• Putting the pieces together into a finished video that is ready to post.
• Deciding what quality is good enough to show a customer, and what is not.

That is the work a model update cannot take away. If I picked a different model tomorrow, the product would still be Bolo, because the judgement sits outside the model. I have written more about the language side in why Indian languages are still hard for AI voice.

Cost is part of control

One kind of dependence is easy to miss: cost. If the price of a model call rises, the margin on every order shrinks. For a young company where every rupee is watched, this matters as much as quality. I have written about that side separately in how I think about AI inference cost, and about the choice between running your own GPU and calling an API.

If you are curious how different AI video tools compare for Gujarati, Bolo has a practical post on Gujarati AI video tools compared.

Building on rented land, honestly

People sometimes call this "building on rented land". It is a fair phrase. But almost everything is rented in some way: app stores, cloud servers, payment gateways, social platforms where the ads finally run. The goal is not to own every layer. That is impossible for a small company. The goal is to know which layers you rent, what happens when the landlord changes the rules, and how quickly you can move.

I would rather use the best available models today and be ready to change them than wait for a perfect, fully owned stack that never ships. The customer does not care whose model it is. They care that their ad sounds like their language and arrives when they need it. That part is on me, whatever happens upstream.