You Don't Have an AI Product. You Have a Subscription and a Dream.

There's a genre of product launch we've all seen by now. The landing page says "AI-powered" in 72-point type. The demo is genuinely slick. And under the hood it's a system prompt, an API key, and a POST request to a vendor whose logo is on somebody else's pitch deck too.

That's not a product. That's a subscription with a UI. And the difference matters most on the day the upstream provider changes something — which they will, because they don't know your name and they don't owe you a warning.

Let's be clear about the failure modes, because they're not exotic. They're routine.

Deprecation is a calendar event, not a rumor

Model snapshots get retired. Endpoints get renamed. SDKs get a major version that breaks your auth flow. The vendors publish notice windows, and those windows are measured in months — sometimes weeks — and they're measured against their roadmap, not your Q1 launch.

The real question isn't "will this model go away." It will. The question is: could you tell, in a single afternoon, whether the replacement model breaks your product?

If your answer is "we'd have to click around and see," you don't have an integration strategy. You have vibes. Build a small golden dataset of real inputs and expected-ish outputs, wire it to a script, and run it against any candidate model before you flip the switch. That harness is the single highest-ROI thing you'll build this quarter, and it costs less than one bad incident.

The rent goes up whenever the landlord feels like it

Pricing in this space moves. Token prices drop, sure — but they also get restructured in ways that quietly cost you more. Reasoning tokens billed at output rates. Long-context surcharges. Cache reads with their own line item. A retry storm after a timeout that doubles your spend in an hour because nobody put a ceiling on it.

Cost controls aren't an optimization for later. They're a launch requirement:

• Hard per-tenant budget caps with graceful degradation, not a 500 error.
• Prompt and response caching where the workload allows it — you'd be stunned how many identical support tickets get re-answered at full price.
• A router that sends cheap, well-scoped requests to cheap, well-scoped models and saves the expensive one for the hard 15%.
• Output length limits and streaming cutoffs, because a model that rambles is a model that bills.
• A kill switch. One env var that turns the expensive path off. Test it before you need it.

If you can't answer "what did we spend yesterday, per feature, per customer," you're flying blind into a billing surprise.

One API key, one outage, zero customers

Every hosted model is somebody else's infrastructure, and infrastructure has bad days. Regional incidents. Rate limits that bite hardest exactly when traffic spikes — say, the morning of Black Friday, or the hour after your Super Bowl ad, or 2 a.m. when your on-call engineer is asleep and your queue is not.

A second provider isn't a fallback strategy by itself. A second provider you've never evaluated is just a second surprise. What you actually want:

1. A deterministic floor. Rules, templates, cached results, keyword search — something that produces a passable answer with zero model calls. Degraded beats dead.
2. A real circuit breaker. After N failures in M seconds, stop hammering the upstream and route to the floor.
3. Retry with jitter and a cap. Because synchronized retries are how you turn a blip into a self-inflicted DDoS.
4. A status page you actually watch, plus alerting on your own error rate, not the vendor's.

None of this is glamorous. All of it is the difference between a rough afternoon and a postmortem.

Whose data is it, anyway?

Fine-tuning feels like ownership. It usually isn't. Most fine-tuned weights live on the vendor's side, aren't portable, and can't be moved to a competitor without rebuilding from scratch — if you still have the training data in a usable state.

The leverage you actually keep is the boring stuff:

• Your prompt library, in version control, reviewed like code.
• Your retrieval index and the pipeline that feeds it — that's yours even if the model isn't.
• Your eval set, your logs, your labeled corrections.
• Contract terms on data retention, training usage, and deletion, in writing, reviewed by somebody who isn't you.

That pile of messy real-world data and hard-won prompts is the closest thing to a moat you'll get. Treat it like an asset, because it's the only part of this stack a competitor can't rent for $20 a month.

The question that ends the meeting

Ask it out loud: what do we own here?

If the honest answer is "a wrapper and a brand," that's survivable — plenty of good businesses started as wrappers. But it stops being survivable the moment your roadmap assumes the wrapper is the product. Distribution, workflow, proprietary data, and a cost curve that improves with scale: those are the things that hold when the hype cycle rotates and the model of the month changes its name.

The survival checklist, condensed

1. Golden eval set, versioned, runs in minutes.
2. Two viable model paths, both actually tested.
3. Deterministic degraded mode that never touches an API.
4. Per-tenant spend caps and a dashboards-per-feature view of cost.
5. Circuit breaker, capped retries, backoff with jitter.
6. Prompts and configs in git, not in a dashboard somebody forgot the password to.
7. Data retention and training-use terms in writing.
8. A single env var that shuts off the expensive path.
9. Alerts on your error rate and your spend rate, not just uptime.
10. A quarterly drill where you pretend the primary provider went down. It's a fire drill, not a fire.

Ship it anyway, but ship it standing up

None of this is an argument against building with hosted models. It's the fastest way to build, and speed wins early. It's an argument against pretending the dependency isn't there — against the demo that works beautifully until somebody upstream changes a default and your product quietly becomes a spinner.

Bad Boy Software's take: rent the intelligence, own the plumbing. Your customers are paying for the thing that keeps working, not the thing that was impressive in March.

The API key is not a business model. Build like you know the difference.