Subscribe • Previous Issues

The Honeymoon Phase Won't Last: Preparing for AI's Platform Shift

I am old enough to remember the early days of the internet. It was a time when blogs were everywhere and information felt decentralized. Before the giant platforms and their algorithms, the web felt like a collection of independent voices. We had chronological feeds we controlled, not algorithmic ones controlled by someone else.

AI is still in the honeymoon phase, when platforms over-deliver to build adoption. Internet history tells us what typically follows. Right now there’s a mad rush to lock users into a specific model, a specific app, a specific workflow. I get why companies are doing it. But the best models today are often comparable for real workloads, and open-weight options are close enough that tying yourself to one vendor’s roadmap is a choice, not a necessity. I’ve always preferred to keep my options open: use open tools when I can, swap components when I need to, and avoid building around the assumption that any one platform will always treat me well.

What follows is a set of early warning signs. Think of them as “don’t repeat the internet” signals for teams building AI products.

Designing for Exit While It’s Still Cheap

The first warning sign is when access to the core capability narrows over time. In AI, that can mean fewer technical details, fewer deployment options, and fewer ways to inspect or control behavior. You start by experimenting freely. Six months later, you can’t run anything locally, can’t audit what changed, can’t fork a model, and can’t make your own latency and cost tradeoffs. The vendor becomes your runtime, your roadmap, and your risk profile. You also inherit their update schedule. Many of us have noticed providers tweak models behind stable API names. Production applications need version-locking, regression test suites, and dashboards tracking output distributions to catch when behavior shifts overnight.

A second warning sign is policy volatility, often justified as safety measures. Terms of service and acceptable use policies can shift quickly, and enforcement can be inconsistent. The failure mode is not a clean error like traditional software. It’s silent refusals, degraded answers, or a workflow that works Monday and breaks Thursday with no code changes on your side. The model switches from verbose to terse, breaking parsing logic, or shifts output formats, breaking structured extraction.

A more awkward version of policy volatility is geopolitics. Providers can decide they cannot serve certain regions or certain industries, and suddenly your product stops working for those customers through no fault of your own.

Even legitimate use cases can fall into territory that makes providers nervous. Security analysis, healthcare applications, legal research can all trigger unpredictable restrictions, creating reliability problems that have nothing to do with your code quality. The internet version of this was “the algorithm changed.” The AI version is “the model decided it can’t help,” or the platform decided your use case is now out of bounds.

The practical move is to treat multi-provider support like an insurance premium, not a nice-to-have. Keep at least one viable fallback path. Avoid letting vendor-specific features, proprietary formats, or tool calling conventions become the spine of your product. Assume switching costs will be measured in months if you wait until you’re forced.

Keep Your Moat on Your Side

Another early warning sign is asymmetric data flow. Many providers use consumer chat data for model training or improvement unless you opt out. Enterprise and API data is often excluded unless you opt in. The risk is that teams still do real work in consumer chat surfaces, and their proprietary domain knowledge can end up improving a system their competitors can also access. For teams with deep specialized knowledge, repeated corrections and detailed examples can become a high-value signal that you are giving away for free, which can dilute your advantage over time.

Privacy raises a separate concern because context windows often contain sensitive information. When you paste code or customer details into an AI assistant, that data persists in the provider’s logs with specific retention policies. For developers using IDE integrations, the assistant might be seeing every file you open, not just the file you’re actively editing.

My rule of thumb is simple: treat AI input like you’re sending it to an external service you don’t control, because you are. Build guardrails into your code, not just your policy docs. Scan outbound prompts for secrets. Limit context to the minimum. For high-sensitivity workloads, the “right” architecture might include running an open model in your environment, even if you still use a hosted model for general tasks.

Build Like You’ll Switch, Because You Will

A subtler warning sign is the assumption that switching will be easy when you need to. Prompts that work cleanly on one model break on another. Tool calling formats differ. Output that’s reliable in one system gets flaky in another. Teams assume they can swap providers later, then discover that “later” means rewriting prompts, rerunning evaluations, rebuilding tool adapters, and retraining your team to work with a new model.

Embeddings and fine-tuning make this worse. If you build retrieval around one embedding model, moving means re-embedding your entire knowledge base and retuning your pipeline. If you fine-tune on a provider’s platform, you get an artifact that only works there. These techniques aren’t mistakes, but you need to price in the switching costs before you commit.

The practical move is to separate what your product does from which model you’re currently using. Put prompts, tool definitions, and routing logic behind a layer you control. Store conversation state in your own database, not in a vendor’s memory feature. Treat portability the same way you treat observability or backups: as a continuous discipline, not something you retrofit later.

Treat Token Costs as a Product Risk

Token-based pricing makes costs volatile. A prompt change, a longer context window, or a retry loop can spike your bill unexpectedly. Teams have seen cases where adding “explain your reasoning” to prompts doubled costs, or where a misconfigured chain-of-thought prompt made requests 50 times more expensive. You need real-time monitoring, rate limits, and circuit breakers from the start.

Beyond the bill spikes, there’s a longer-term pricing risk that should look familiar. Twitter’s API went from free and open to restricted and expensive. Google Maps had a cutover that forced billing and new keys, and many sites and