When the tool you pay for is not the value you need

A useful way to read today's news is to separate the tool a business pays for from the value it actually needs. An email service is paid for; delivered mail is the value. A customer system is paid for; reachable, current data is the value. When those two drift apart, the monthly invoice keeps arriving while the thing you were buying quietly stops showing up.

Outlook delays put reliability back on the table

Microsoft said it is testing a fix for a widespread Outlook problem that produced email delays and failures over several hours [1]. For a business, the detail that matters is not the cause but the shape of the exposure: email is usually treated as always-on plumbing, so very few teams have a written answer for the hours when it is not.

The lesson is about dependency, not about any one provider. Every tool you rely on has an availability profile, and most buyers never ask about it until an outage forces the question. Three practical checks follow from a day like this. First, know how you would find out — do you learn from a status page, a customer complaint, or silence. Second, know what still works when email is delayed: can a colleague reach a customer another way, and is there a record of who was mid-conversation. Third, know whether the delayed messages eventually arrive or are lost, because those are very different problems to recover from.

None of this means moving off a service that millions depend on. It means treating reliability as a feature you evaluated on purpose rather than one you assumed. When a tool is the single path for something that matters, the absence of a second path is a decision you have made, whether or not you noticed making it. We write more about judging software on the attributes you will actually depend on in choosing software worth using.

Paying for a system, using only its data

SaaStr published an account of running Salesforce without its interface for more than six months — an arrangement they call "Claudeforce." In their words, "We still pay for it. We still depend on it. We just stopped using the UI as the primary way to get at any of it" [2]. The data stays in place; what changed is how people reach it.

This is worth slowing down on, because it separates two things that are easy to conflate. A system of record holds your data and enforces its rules. The interface is one way to read and write that data. You can value the first highly and still decide the second is not how your team wants to work day to day. The arrangement SaaStr describes keeps the record and swaps the front door.

There is a trade-off, and it is honest to name it. An interface built and maintained by your vendor comes with guarantees you now take on yourself: permissions, audit trails, validation, and the discipline that stops two people overwriting each other. Reaching data directly is faster for the person doing it and riskier for the organisation if those guarantees are not reproduced somewhere. The useful question this raises for any buyer is not "should we go headless" but "how much of what we pay for is the data, and how much is the interface, and can we tell the two apart." A system you cannot get your data out of has answered that question for you. We have written separately about the data you should be able to export on any Tuesday, because the ability to reach your own records is the floor beneath every arrangement like this one.

The broader pattern is that interfaces and underlying systems are starting to come apart. For years the two were sold as one thing. Accounts like this suggest some teams now treat them as separable, keeping the store of record and choosing their own way in. Whether that suits you depends on whether you can carry the guarantees the old front door used to provide.

The infrastructure under the tools you buy

Further down the stack, Nvidia invested 3.5 billion dollars in the Taiwanese chipmaker MediaTek [3]. TechCrunch frames the move as a sign of how Nvidia "plans to stay essential to AI infrastructure as Big Tech begins to build its own AI chips" [3].

This looks distant from a business choosing between two subscriptions, but it is the layer those subscriptions sit on. The AI features appearing across productivity software run on hardware built and supplied by a small number of companies. When those suppliers reposition, the cost and availability of the features you are being sold can shift underneath you, on a timeline you do not set and often cannot see.

The practical takeaway is modest. You do not need a view on chip strategy. You do need to notice when a feature you are coming to rely on depends on a supply chain several steps removed from your contract. A capability that is cheap and plentiful today because the underlying market is competitive may be priced differently if that market consolidates. That is not a reason to avoid AI features. It is a reason to treat the ones you build real workflows around as decisions with a cost that could move, and to keep the manual path working underneath, as we argued in decisions automation should never make.

A reminder that not every problem is a tooling problem

SaaStr also answered a founder asking whether to remove an underperforming sales rep who is tied to a key deal, or wait for the deal to close. Their advice is direct: "Move on from the rep now" [4].

It belongs in a briefing about tools precisely because it is not about tools. No system will resolve a people decision that a manager is avoiding, and reaching for software to defer the choice usually makes the delay look like diligence. The pattern the answer describes — holding on because one deal is entangled — is a judgement about people and risk, and better data only sharpens it rather than making it for you.

The connection to the rest of the day is the same thread. A business gets into trouble when it mistakes the tool for the value. Email software is not delivered mail. A customer system's interface is not its data. A sales tool is not a working sales team. On a day when each of those gaps was visible somewhere, the discipline worth keeping is to name what you actually depend on, check that you can still reach it when the tool wobbles, and make the decisions the tool was never going to make for you.

If you are reviewing your own stack in that light, two earlier pieces give a place to start: a clear account of what a CRM is actually for, and a look at why your tools do not talk to each other.