The tools under you keep changing shape

Choosing software is not choosing a fixed object. It is choosing whose decisions you will live with, because the tools you depend on keep changing shape under you — some by growing, some by buying their way into new markets, and some by deliberately doing less. Thursday's news ran along that single thread, and each item is really a question about dependency: who keeps improving, who consolidates, and who slows down on purpose to protect you.

The build-versus-buy question, answered honestly

The oldest decision in business software is whether to build a tool yourself or buy one that already exists. It sounds like a technical question. It is really a question about where your time should go. Every hour spent building and maintaining an internal tool is an hour not spent on the thing your customers actually pay you for. That is why, for most businesses, the default answer leans hard toward buying — you buy the thing, you get on with your work, and you let the vendor carry the cost of keeping it current.

SaaStr made this case plainly on Thursday, arguing that artificial intelligence will not end the software-as-a-service model but will punish vendors who stop improving their products. The piece frames the decision as a rule of thumb weighted heavily toward purchasing: "If you can buy it — buy it." [1] The interesting part is the condition attached. Buying is the right call only when the vendor keeps shipping — keeps fixing, extending, and responding. A product that has stopped moving is no longer really a purchase; it is a slowly expiring dependency you have not noticed yet.

The practical lesson for anyone evaluating tools is to look past the current feature list and ask about momentum. When did this last change in a way that helped me? How often does it change? A vendor's release history tells you more about the next three years than any demo does. We have written before about how to read a product this way in choosing software worth using, and about the quiet expense of deferring the decision in the real cost of well build it later.

Slowing down updates on purpose

There is a version of "keeps shipping" that looks like the opposite. On Thursday, GitHub described a change to Dependabot, the tool that opens pull requests when a new version of one of your software dependencies is released. Instead of proposing an update the instant a version appears, Dependabot now waits by default.

The reasoning is worth understanding even if you never touch code. When a new version of a widely used library is published, it is not yet proven. Problems — including security problems introduced deliberately into a release — are often found in the hours and days after publication, not before. Rushing that version into your own systems means you inherit those problems before anyone has had time to catch them. GitHub's post explains the new default this way: "A new default three-day cooldown delays version update pull requests so maintainers and security researchers can address findings in a release before it gets into your code." [2]

This is a useful mental model far beyond dependency management. Being first to adopt any new release is not automatically prudent. A short, deliberate delay — letting other people find the sharp edges first — is often the safer setting for anything you did not build and cannot fully inspect. The same instinct applies to auto-updating apps, new plan tiers, and features flipped on by default. It is the discipline behind keeping a clear record of what changed and when, which we covered in the audit trail nobody thinks about.

When your vendor gets much bigger

Two items on Thursday were about vendors growing, and growth cuts both ways for the businesses that depend on them. A larger, financially healthy vendor is more likely to still be there in five years and more likely to keep investing. A vendor that is busy acquiring and expanding is also a vendor whose attention is divided, and whose priorities may drift away from your particular use case.

SaaStr summarised a set of figures on Stripe, the payments company, reported this week: revenue of 6.8 billion dollars, growth of about a third year on year, strong free cash flow margins, and a 53 billion dollar bid for PayPal. The write-up opens with a caution that matters when you read any private company's numbers: "Stripe is still private, so we mostly get data when the company chooses to give it to us." [3] That is the honest frame. You are seeing what the vendor elected to show. It tells you the business is large and growing, which is reassuring for anyone who depends on it. It does not tell you everything, and a very large acquisition is also a signal that the company's shape is about to change.

The second growth story was more targeted. TechCrunch reported that ServiceNow is investing 40 million dollars in an Indian banking-software specialist, BusinessNext, at a 700 million dollar valuation, to push further into financial services. The report describes the aim directly: "ServiceNow's investment gives BusinessNext a strategic partner to expand its AI-powered banking software globally." [4] For a business, the read-through is about verticalisation. General platforms are increasingly buying their way into specific industries. If you work in one of those industries, the tool you use may soon come with features built for you — and may also start optimising for customers who are not you.

A small feature about who acts for whom

Not every announcement is strategic. Some are small, and the small ones are often the most immediately usable. Google Workspace said that when you view a guest list in Google Calendar on the web, an icon will now appear next to people who have a calendar delegate — someone authorised to manage their scheduling. Google describes it plainly: "When viewing a guest list in Google Calendar on the web, you will now see a new icon next to leaders who have a calendar delegate assisting them with scheduling support." [5]

This is a delegation-visibility feature, and it points at a principle every tool should respect: when one person acts on behalf of another, that fact should be visible, not hidden. Knowing who really controls a calendar changes how you schedule around it. The broader idea — that permissions and delegation should be legible rather than opaque — sits close to why access and identity deserve deliberate design, which we discussed in one login and why it matters.

What to take from the day

Four of Thursday's items were about the same underlying fact from different angles. Software you depend on is not static. It gets better when the vendor keeps working; it gets safer when updates are treated with a little patience; it changes character when the company behind it grows or buys its way into a new market. The questions worth asking when you choose a tool are therefore less about today's features and more about direction: does this vendor keep improving, does it handle change carefully, and is its growth pulling it toward businesses like mine or away from them.

At 360REV we build with that same bias toward buying proven pieces and improving steadily rather than chasing every new release. That is the whole point of watching the day's announcements: not to react to each one, but to read the direction they point.