Depending on the software you buy

Three announcements today circle the same question: what exactly are you agreeing to when you adopt a piece of software. One concerns whether the service stays up, another concerns how you will be charged as the work shifts to machines, and a third concerns who is really doing the work once an AI agent sits between you and the result.

When the service you depend on goes down

Every tool you adopt is a dependency. While it is running you forget it is there; when it stops you discover how much of your own operation was resting on it. GitHub published an update describing a recent outage and the steps it is taking afterwards, framed as "An update on the August 17 outage and the steps we're taking to improve reliability." [1] For a business choosing tools, the detail of any single incident matters less than the posture a vendor takes once one has happened.

A useful signal is not the absence of outages, because every service of any size has them, but what the provider does in the open when one occurs. Does it say what broke, name the work it is doing, and give you something to judge it by over time. A supplier that writes plainly about a bad day is easier to trust than one that stays quiet. So when you are weighing a tool, read its incident history before you read its feature list, and ask how you would keep working during the hours it is unavailable, because those hours will come. That is part of what it means to choose software worth using, and part of what enterprise-grade should mean to a small business: not a promise that nothing ever fails, but a plan for when it does and a record you can inspect.

The pricing playbook is changing

Stripe published a piece on monetisation trends drawn from pricing leaders around the world, opening with the observation that "As AI transforms software economics, the standard revenue playbook is breaking down." [2] It is worth sitting with why.

For most of the past two decades, software pricing meant a subscription charged per seat. It was predictable, and it rewarded getting more people into the product. When software does the work itself through agents, that link weakens. The cost to run the service tracks the volume of work done, not the number of people logged in, and the value a customer feels tracks outcomes rather than access. That pushes pricing towards usage and outcomes, and it changes the question a buyer should ask. Instead of "how many seats do I need," ask "what happens to my bill when volume spikes, and can I see it coming."

Before you sign, look for three things: whether you can predict the bill in a normal month, whether there is a ceiling when a busy month arrives, and whether you can export your own usage data to check the invoice yourself. A pricing model you cannot forecast is a risk you are taking on, not a convenience. This is the same ground covered in how pricing pages fail: the page that hides the mechanism is the one that will surprise you later.

When the product is an agent, not a screen

SaaStr wrote about a vertical B2B company that grew past $100M in annual recurring revenue on the back of agents. Its starting point is that the debate about whether to build with AI is settled: "Everyone agrees you have to build with AI now." [3] The sharper idea sits in the piece's own headline, which frames the goal as a product where every time a customer logs in, the company has failed.

That inversion is worth understanding. Traditional software measures engagement — logins, sessions, time spent in the app — and treats more of it as success. A product built on agents measures the opposite: work completed on the customer's behalf without the customer having to show up at all. If the tool is doing its job, the person it serves should need it less often, not more.

For a buyer, this changes what you should ask a vendor to prove. Not "how sticky is it" but "what outcome does it deliver, and how would I measure that." It also raises the stakes on control. An agent that acts for you needs boundaries, a record of what it did, and a clear line between the decisions it may take and the ones it must bring back to a person. That line is the subject of what AI should and should not do in your business, and it matters more, not less, as the product moves from a screen you operate to an agent that operates on your behalf.

Admin controls decide who can do what

Google announced that an administrative tool in Workspace has moved from manual management to a programmable one: "The Google Workspace Allowlisted Domains API is now generally available." [4] The change sounds narrow, and for a very small team it is. The reason to notice it is what it represents.

Governance controls — who can share with whom, which outside organisations are trusted, who can create what — feel like overhead until a business has more than a handful of people. Then they become the difference between a system you can reason about and one you cannot. Moving a control from a console a person clicks through to an interface another system can call means the rule can be applied consistently, checked automatically, and kept in step as the organisation changes. When you evaluate a platform, it is worth asking not only what it does for your end users, but what it lets an administrator see and enforce. The tools that scale with you are the ones where the controls scale too.

Building instead of buying

Xero wrote about small businesses and their advisers customising their own tools, opening on the old trade-off: "For years, when a small business or advisor hit a workflow problem, the answer was to find an app that solved it or live with a workaround." [5] The piece's premise is that this is shifting, as building a solution gets cheaper.

The build-versus-buy decision has always had two sides. Buying gives you something maintained by someone else, at the cost of fitting your work to their assumptions. Building gives you a fit to your exact process, at the cost of owning it forever — every change, every edge case, every person who has to learn it after the one who made it has gone. What lowers the cost of building, including AI, does not remove that second cost; it just moves the line of when building is worth it. Before you build, ask who maintains it in a year, and whether the thing you are replacing was a real constraint or a habit.

The thread

Reliability, pricing, agents, controls, and the choice to build — five different stories, one underlying question. When you bring a tool into your business you are not buying features; you are taking on a dependency whose terms you should understand before, not after. Read the incident history. Forecast the bill. Ask what the product measures as success. Check who can enforce the rules. And know the full cost of anything you decide to build yourself. None of these are glamorous questions, and all of them are cheaper to ask now than to learn later.