When a vendor goes down and what it teaches

Today the news circles one plain question: what happens to your work when a tool you rely on stops working. Three posts from the publishers approach it from different angles, and together they make a case for treating every vendor relationship as a decision you keep reviewing rather than one you make once.

The cost of leaning on a single vendor

Most businesses carry what is called concentration risk without naming it. One product sits underneath a core workflow, everything else connects to it, and the day it fails is the day you discover how much you had resting on it. The risk is not that the tool is poor. Good tools fail too. The risk is that you have no second path when it does.

SaaStr described exactly this. One of the core products they run their own operations on was unavailable for a full day. In their words, "The other day one of the core products we run SaaStr AI on went down the entire day." [1] The detail that matters for anyone choosing tools is not the brand that failed. It is what the failure exposed: when a dependency is total, its downtime is your downtime, minute for minute.

There are two ways to reduce that exposure. The first is to know, before you commit, which single tool your day cannot run without, and to accept that you are buying its outages along with its features. The second is to keep a manual fallback for the handful of tasks that genuinely cannot wait. A fallback does not need to be elegant. It needs to exist and to be known by the people who would reach for it at nine in the morning when the main screen shows an error. This is also why the question of what you let software decide on its own deserves a settled answer in advance, which we have written about in decisions automation should never make.

We built 360REV so that the records a business depends on stay readable and exportable even when a connected service is unavailable. That is one sentence about us, and the point stands with or without us: ownership of your own data is the cheapest insurance against someone else's outage.

What to actually check before you commit

When you evaluate a tool, outage behaviour is a line item, not an afterthought. A few questions do most of the work:

• If this is down for a day, which of my tasks stop entirely?
• Can I get my data out today, in a format I can open without this vendor?
• Is there a slower manual route I could run for a day, and does anyone on the team know it?

None of these require a crisis to answer. They require ten minutes during the trial, while you still have the leverage of not having bought yet.

Reading the week's market signals

The stability of a vendor is not only about uptime. It is also about who owns it, how it is funded, and whether its strategy is about to change under you. These things rarely show up in a feature comparison, but they shape the tool you will be using in two years.

SaaStr's weekly round-up is useful here precisely because it treats the market as context for operators, not just investors. The format is a standing conversation: "Every Thursday, Harry, Rory and I go through the week's news on 20VC x SaaStr." [2] The value for a buyer is in the habit, not any single headline. Watching how the people who fund software read ownership changes, buyout offers and funding rounds tells you which products are likely to shift direction, raise prices, or be absorbed into something larger.

You do not need to trade on any of this. You need to notice when a tool you depend on is about to change hands or change course, because that is the moment to reconfirm your fallback and to check that your data can still leave. A vendor that is stable today can be a different company after an acquisition, and the switching cost you quietly accepted becomes a bill you did not plan for.

The practical move is to keep a short list of the three or four tools that would hurt most to lose, and to glance at the market around them every so often. That is a far cheaper discipline than discovering a change after it has already reorganised your week.

The habit of shifting your own perspective

The third item is lighter, and I include it because the idea underneath it is worth borrowing. GitHub's annual game jam returned with a single-word brief: "This November, make a game inspired by the theme SHIFT." [3] The prompt is aimed at game developers, but the instinct it rewards is one every business could use more of. A shift is a deliberate change of footing, taken before you are forced into one.

Most tool problems are not sudden. They build up while a workflow keeps working well enough that no one questions it. The spreadsheet that was fine at ten customers is strained at two hundred, and nobody noticed the day it crossed over. We have written before about when a spreadsheet stops being enough, and the pattern generalises. The tools you chose for the business you had are not automatically right for the business you now run.

So borrow the brief. Once a quarter, shift perspective on purpose. Ask what you would choose if you were starting today, with no sunk cost and no familiarity to protect. You will usually keep most of what you have, and that is fine. The value is in the one or two places where the honest answer is that you would not choose this again, because those are the dependencies quietly growing into the next outage you have to survive.

What ties the day together

An outage, a market round-up and a game jam do not obviously belong in the same briefing. What joins them is a single discipline: do not treat your tools as settled. Know what fails when they fail, watch what is happening to the companies behind them, and make a habit of questioning the setup before it questions you. If you want a fuller view of where the line between human judgement and automated action should sit, start with what AI should and should not do in your business, and see yesterday's notes in the daily briefing for 30 October.