I’ve Seen This Pattern Before. Are You Building for What Comes After Cheap AI Access?

I shut down a SaaS product a few years ago. Not because the idea was wrong, and not because the market wasn’t there. Because the platform underneath it changed ownership, repriced its API overnight, and what had been a viable foundation rapidly became an unworkable cost centre.

I’ve been watching the AI space closely ever since.   I’m seeing the same structural pattern forming -just with larger numbers, more VC money, and bigger stakes.

This post isn’t about what I lost. It’s about what I think is coming for a lot of people building on LLM APIs right now, and what you can do about it before it happens to you.

Some Background, How I Know What a Rug Pull Feels Like

In 2013 I started building a product called Social Opinion. The idea was to use NLP and sentiment analysis to mine social data for real-time signals of commercial intent, then enable marketers to act on those signals with targeted advertising.

Right message, right person, at the right time.

It worked well enough that the platform I’d built on top of invited me to their HQ’s in San Francisco and New York.

They gave me access to internal alpha APIs. They told me in writing that they were “invested in this partnership” and intended to “move forward at full speed.”

A few years later, under new ownership, they killed free API access with almost no notice. The product I’d built entirely on top of that access was no longer viable. I shut it down.

I’m not telling that story for sympathy. I’m telling it because the dynamics that played out are almost identical to what’s happening in AI tooling right now, and most people building in this space haven’t lived through the other side of it yet.

~

What’s Happening in AI Right Now

Many products are being built on top of Open AI, Anthropic, Google, and other LLM providers. The access is cheap. In some cases it’s nearly free, backed by organisations willing to absorb losses while pursuing long-term strategic goals.

That’s a deliberate strategy. Get builders dependent on your infrastructure. Get end users habituated to the experience. Then, once the ecosystem is locked in, figure out the economics.

None of that is secret. The providers aren’t hiding it. But there’s a gap between knowing something abstractly and actually pricing it into your product decisions, and right now, a lot of teams are building as if today’s API costs are a permanent feature of the landscape rather than a temporary one.

~

The Specific Risks Worth Naming

Some risks to consider and worth noting:

• Pricing isn’t static. Today’s API costs reflect a market that’s still expanding rapidly, with providers prioritising growth, adoption, and market share alongside profitability. As those priorities evolve, pricing will too. If your product’s unit economics only work at today’s rates, you’re relying on an assumption you don’t control. Know where your break-even point is before someone else decides it for you.
• Ownership and strategy changes. I know what it looks like when a platform changes hands and the new owners have different priorities. Models get acquired. Labs get bought. Priorities shift. The relationship you have with a platform today is only as stable as that platform’s ownership and incentive structure  -neither of which you control.
• Model deprecation. The specific model your product is tuned around may not exist in two years. Providers are moving fast, retiring older versions, and the prompt engineering, fine-tuning, or integration work you’ve done against a specific version doesn’t automatically transfer. This isn’t hypothetical -it’s already happening.

What you’re allowed to build on top of a given API can change. Use cases that are permitted today may be restricted tomorrow. Output you’re allowed to store, repurpose, or sell downstream is subject to terms that can be updated with relatively little notice.

~

This Isn’t an Argument Against Building

It would be easy to read this as “don’t build on LLM APIs.” That’s not what I’m saying. The capabilities available right now are remarkable, and the right time to build with them is while the access is good and the cost is manageable.   I am building with these tools too.

The argument is about how you build. Specifically, about whether you’re designing for the risk that already exists, or pretending it doesn’t.

~

How I’d Build It Today

Having been burned before, here are some things to approach differently:

• Abstract the model layer from day one. Your application logic should not be tightly coupled to a specific provider or model. If switching from OpenAI to Anthropic to an open-source alternative requires a significant rewrite, you’ve already lost flexibility you’ll eventually need.
• Model your unit economics at 10x current API cost. If the product stops working at ten times today’s inference price, that’s a risk you’re carrying. Know where the break-even is. Have a plan for what you do when, not if, costs move.
• Watch where the VC money actually is. The providers keeping prices low are doing so with someone else’s capital. Track the funding cycles, the runway signals, the revenue disclosures. When the subsidised period ends, it tends to end fast.
• Don’t mistake a good relationship for a contractual one. A dedicated support contact, early access to new models, enthusiastic partnership emails  -these are signs of goodwill, not protection. Goodwill is not transferable when ownership changes.
• Keep an eye on open-source alternatives. The gap between frontier closed models and capable open-source alternatives is narrowing. Building with an awareness of what you could run yourself, if you had to, changes the risk calculation significantly.

Make sure you’re building assets that survive the product.  This might be skills, architecture patterns, domain knowledge, or customer relationships.  The things that compound regardless of what happens to any specific product or API.

~

Transparency

I didn’t fully apply these rules when I was building Social Opinion. I knew platform risk was a concept. I didn’t treat it as an active design constraint. The relationship with the platform felt strong enough that I underweighted what would happen if it changed.

What did I get out of it?

The NLP work, the real-time architecture, the understanding of intent detection at scale, the experience of presenting a product at a global competition -none of that went away when the product did. That part I did right, even if accidentally.

But I’d have built the product differently if I’d genuinely designed for the risk from the start. If I were starting something today on top of LLM credits that exist because a hyperscaler is buying market share, I’d be asking harder questions about what the product looks like when those credits cost ten times as much.

Whether it happens in two years or ten is impossible to know. The point is that platform incentives eventually change.

But platforms eventually optimise for their own economics, not yours.

If you’re building on someone else’s infrastructure, design as though that day will come.

~