Commentary
What Anthropic’s Stainless Acquisition Reminds Every Business
A practical reminder that business-critical software dependencies often become utilities before leaders recognize the risk.
When Software Becomes a Utility
A company most of us have never heard of is now part of a much bigger conversation.
On May 18, 2026, Anthropic announced that it had acquired Stainless, a developer tooling company founded in 2022.1 Stainless turns API specifications into SDKs, CLIs, MCP servers, and other connective tissue that helps developers and AI agents use software systems reliably. According to Anthropic, Stainless has powered every official Anthropic SDK since the early days of its API, and hundreds of companies rely on it.
That same week, TechCrunch reported that Stainless had also been used by companies including OpenAI, Google, and Cloudflare.2 Stainless announced that it would wind down its hosted products, including its SDK generator; customers retain the SDKs already generated for them and the right to modify them.3
For most business owners, that may sound painfully technical. Fair. The larger lesson reaches beyond software engineering: We often treat software like an app until the day we discover we depend on it like electricity.
There is no need to panic. It is time to understand the utilities our businesses depend on.
Dependency Is Normal
Acquisitions are ordinary business. So are dependencies.
Modern businesses are built on shared utilities. Few companies generate their own electricity, run their own internet backbone, manufacture their own phones, write their own database engines, or build every workflow tool from scratch.
Invisible dependency is the problem.
When a tool is convenient, we experiment with it. When it saves time, we adopt it. When it becomes embedded in the way work gets done, we often forget to promote it in our minds from “tool” to “utility.” Then ownership changes, pricing changes, terms change, access changes, roadmaps change, or the service disappears, and everyone suddenly realizes the thing was load-bearing.
The Utility Test
A utility is not defined by whether it looks boring, regulated, or permanent. A utility is defined by what happens when it stops working.
- If your business cannot send invoices without it, it is a utility.
- If your team cannot authenticate users without it, it is a utility.
- If your developers cannot ship safely without it, it is a utility.
- If your sales process stops, your customer support breaks, your website fails, your reports go dark, or your AI workflow collapses without it, then it is no longer just a tool.
Then, it is part of your business infrastructure and you need to understand it.
Why This Acquisition Is a Useful Reminder
The Anthropic and Stainless story sits in a connective layer of technology: the software that helps developers and systems talk to APIs reliably. It is easy to underestimate because most people never see it.
Business owners may not care how SDKs are generated. They may not know what an OpenAPI specification is. They may never hear about the company “Stainless” again after this week.
But they do understand what it means when a supplier becomes strategic. They understand what it means when a vendor is acquired, a service they relied on changes direction, or the tool that used to “just work” becomes a boardroom topic after something goes wrong.
Many acquisitions make products better, give teams more resources, and accelerate useful work. But once software becomes a utility, ownership matters more.
The Quiet Problem: Tools Become Infrastructure Slowly
Most businesses do not wake up one morning and intentionally decide that a small tool is now mission critical. It happens quietly.
A team tries a tool because it solves a problem. A few people like it. Someone builds a workflow around it. Another team copies that workflow. A dashboard uses its data. A customer process depends on it. A contractor adds it to an automation. An intern documents it in a checklist. A manager starts expecting the output every Monday morning.
At no single moment does the company stop and say, “Congratulations, this is now critical infrastructure.”
I watched this happen with a reporting data mart and its nightly refresh process. What began as a practical way to make operational data easier to query gradually became the source behind dashboards, extracts, management reports, and daily support work across the organization.
If the refresh failed, the source system still existed, but the business could not simply switch back to it. Downstream reports expected transformed, reconciled data to arrive in a particular shape each morning. We reduced that risk by staging and validating each new load before publishing it. If the checks failed, the process aborted and users continued reporting from the previous day’s validated data rather than receiving incomplete or misleading numbers from a bad run.
The fallback did not eliminate the disruption. Some reports became stale, urgent questions required investigation, and the failed load still had to be repaired. But the business degraded safely instead of publishing data we no longer trusted.
No formal announcement made the refresh critical infrastructure. Its criticality became visible in the safeguards we had to build around it.
The risk appears when the business depends on a tool it has never mapped.
Questions Every Business Should Ask
This does not require a massive governance program. For many small and midsize businesses, it can start with a simple utility map.
For each important system, ask:
What do we depend on? List the platforms, tools, APIs, vendors, libraries, cloud services, payment processors, authentication systems, AI services, reporting tools, and automation platforms that keep the business moving.
What stops if this stops? Be honest. Some tools are annoying to lose. Others stop revenue, operations, customer service, compliance, payroll, or delivery.
Who owns it? Ownership matters. A tool owned by a tiny startup, a major cloud provider, a private equity firm, an open-source foundation, a competitor, or a strategic AI lab may carry very different risks.
Who could buy it? You do not need a crystal ball. You need awareness. If a tool is strategically valuable, assume someone else may eventually decide it is valuable too.
How fast could we move? If pricing changed, access changed, terms changed, performance degraded, or the product shut down, could you move in a day, a week, a month, or not at all?
Do we have an exit path? An exit path does not always mean an immediate migration. Sometimes it means backups, exported data, documented workflows, alternate vendors, open standards, internal knowledge, or a written plan that says what to do first.
Depend With Your Eyes Open
Outside tools can be a sound business decision. Resilience means:
- knowing which dependencies are ordinary, which are strategic, and which are existential.
- knowing where software has become a utility.
- noticing when a helpful tool has become part of the nervous system of the business.
- not waiting for an outage, acquisition, price hike, policy change, or vendor shutdown before asking basic questions.
The Practical Takeaway
The Anthropic and Stainless acquisition is a reminder that some software functions have become utilities. They carry work between systems and quietly hold up customer, operational, and technical processes.
When software becomes a utility, map it, ask honest questions, and plan before the business is surprised by what it was standing on.
For business leaders, dependency literacy belongs beside vendor management.
Know which tools keep the lights on.