The tools around your tools

A tool is never chosen on its own merits alone. Thursday's announcements were, in different ways, all about the things that sit around a tool — whether it reaches the software you already run, and whether the company behind it will still be standing when your renewal comes due.

That is the quieter half of any buying decision. Features are easy to compare on a page. What is harder, and more expensive to get wrong, is the question of fit: does this thing work with everything else, and is the vendor durable enough to keep working with everything else next year. The day gave four useful data points on that question.

Calendars that reach across rival meeting tools

Most teams do not run a single video product. One client insists on one tool, a supplier uses another, and your own staff default to a third. The calendar is where that fragmentation becomes a daily tax: a meeting link that only half the invitees can open cleanly, a dial-in buried in a description field, a few wasted minutes at the start of every call.

Interoperability is the plain word for the fix. It means a piece of software is built to cooperate with products made by other companies, rather than assuming everyone lives inside the same suite. When you are weighing a calendar or a meeting tool, the interoperability question is simple to ask and revealing to answer: can a person on a different email and calendar system join the meeting without friction.

Google addressed exactly this on Thursday. Its update says, "We are introducing improvements to Google Calendar that make it easier to join third-party video meetings, including Microsoft Teams, Zoom, and Cisco Webex, when collaborating across different calendar and email clients" [1]. The detail that matters for a buyer is the phrase "across different calendar and email clients" — the improvement is aimed at the mixed environment, not the tidy single-vendor one. This is the same principle we have written about before in why your tools do not talk to each other: the value of a tool is capped by how well it connects to the ones on either side of it. A product that only works beautifully inside its own walls is making a bet that your whole organisation, and everyone you work with, will live inside those walls too.

The short list of software vendors still growing fast

Durability is the other half of fit. A tool that connects to everything is of little use if the company behind it stalls, stops investing, or gets absorbed and left to drift. Growth rate is one of the few public signals a buyer can read about a vendor's health, because listed companies have to report it.

SaaStr published a count on Thursday that is worth keeping in perspective. It reports, "Seven public B2B software companies are growing faster than 30%" [2]. Seven is a small number. For a decade, 30% annual growth was an ordinary expectation for a software business of any ambition; the fact that only a handful of public ones now clear it tells you the market has matured and the easy growth has thinned out. The piece also notes how it does its sums: "Annualized is that quarter's revenue times four" [2] — a rough method, which the author flags, but good enough to sort the field.

For someone choosing tools, the lesson is not to chase whichever vendor is growing fastest. It is to read the growth figure as context. A vendor growing slowly is not failing; most good, established software grows slowly now. But if you are paying a premium on the promise of rapid expansion and relentless new features, the public numbers are a reality check on whether that promise is common or rare. We made the broader version of this argument in choose software worth using: the decision is about the next several years, not the demo.

Why accounting practices are rethinking their habits

Sometimes the thread running through a tool decision is not the tool at all, but the work it is meant to support. Accounting and bookkeeping is a clear case, because the job itself is changing underneath the software.

Xero framed the moment directly on Thursday, writing that "The accounting and bookkeeping profession is at an inflection point" [3]. The post is about habits rather than products — how the practices that are pulling ahead are changing the way they work, under pressure from automation, rising client expectations, and competition. That framing is the right one for any buyer in a field being reshaped by automation. The habit comes first; the tool supports the habit. Buying new software and bolting it onto an old way of working rarely produces the gain that was promised, because the constraint was never the software.

The practical move is to decide what the new habit should be — how often you reconcile, how you talk to clients, what you want automated and what you deliberately keep human — and only then ask which tool fits that habit. A vendor's own account of where its profession is heading, as Xero gives here, is useful reading precisely because it tells you what the tool is being built to assume.

What a viral open-source project teaches about dependencies

Finally, a reminder that many of the tools you rely on are built on tools you never chose. Open-source components sit inside almost every piece of software a business runs, and the health of those components is part of the health of your stack.

GitHub profiled one such project on Thursday, opening with the claim that "OpenClaw is the fastest-growing project in GitHub history" [4]. Speed of adoption is not the interesting part for a buyer. The interesting part is who stands behind it: the piece gathers the maintainers to share "what they learned in the project's first six months" [4]. A dependency that millions rely on may be maintained by a small number of people, and understanding who they are, and how they handle security, is part of understanding your own exposure.

The point for a non-technical decision-maker is modest but real. When you ask a vendor what their product is built on, and who maintains those parts, you are asking the same durability question as the growth figure above, one layer down. A tool is only as dependable as the least dependable thing beneath it.

Four announcements, one thread. The tool is rarely the whole decision. What surrounds it — the connections, the vendor, the work, the dependencies — is where the risk and the value actually sit.