Your uptime is your vendor's uptime

The morning it broke, nothing in their own codebase had changed. No deploy, no migration, no clever Friday refactor waiting to ambush them. The contract-review product simply stopped reviewing contracts, returned errors to every customer who tried, and the team spent the first frantic hour searching their own work for a bug that was never there. The outage was a thousand miles away, on infrastructure they did not own, run by a company whose status page they had never thought to check.

The model provider was having a bad day. So, therefore, were they.

The product was built on an external model API, the way most AI products now are, and for good reason. You do not train your own frontier model to review contracts any more than you generate your own electricity to run the office. You plug into someone who does it better, and you build the valuable part on top. That trade is correct. The mistake was forgetting that the trade was made at all, building as if the API was a local function that always returns, when it is really a dependency on another company's worst day.

Every external API is a promise made by someone who is not in the room when it breaks.

It does not even have to be an outage. The provider can deprecate the model version you depend on and give you ninety days to migrate. They can change their pricing and turn your healthy margins into a meeting. They can tighten a content filter and start refusing inputs that used to work fine, or quietly adjust the model's behaviour so your carefully tuned prompts drift. Each of these is a Tuesday-morning surprise authored entirely by someone else, and the first you hear of it is your own product behaving strangely while your code sits there, innocent and unchanged.

None of this is an argument against using the vendor. It is an argument against pretending the vendor is part of you. The fix is to build the seam on purpose. Put the dependency behind your own interface so swapping providers is a configuration change, not a rewrite. Decide, in advance and in writing, what your product does when the model is unreachable: degrade to a smaller backup model, queue the work and tell the customer honestly, fail in a way you designed rather than a way that surprises you. Watch the provider's status the way you watch your own. Their incident is your incident, several minutes before your customers make it loud.

The companies that ride these moments out are not the ones who picked a vendor that never fails. There is no such vendor. They are the ones who assumed the failure, drew it into the architecture, and decided ahead of time what their product would do on the morning the promise wasn't kept.

You can build on someone else's model and still own your uptime. But only if you design for their bad day before it arrives, because it will, and it will not call ahead.

TensorLabs designs for the vendor's bad day as a matter of habit. The vendor will have one. The only question is whether your product already knows what to do about it.