By Helal Chowdhury
What if the next company capable of disrupting an entire industry is not a bank or technology giant, but an obscure software provider whose name its customers barely recognise?
In April 2024, the bankruptcy of Synapse, a US fintech intermediary, left thousands of people unable to access money held through partner banks. Synapse connected financial applications to banking services and maintained records needed to reconcile customer balances. When that arrangement broke down, banks had not necessarily failed, but customers still could not get their money.
The lesson is unsettling: a business does not need to own an asset to become indispensable to everyone who does.
Two months later, a cyberattack on CDK Global disrupted software used by roughly 15,000 car dealerships across North America. Dealers resorted to manual processes for sales, financing and service operations. CDK was an established company, not a startup. Its outage showed what dependence looks like when an industry runs critical tasks through a small number of providers.
I believe we are judging software companies by the wrong numbers.
Investors measure revenue, valuations and customer growth. Buyers compare features, prices and promised uptime. But few ask a more consequential question: how many otherwise healthy businesses could stop functioning if this supplier disappeared?
A service-level agreement promising 99.9% uptime will not rescue a retailer whose transaction history is trapped inside a failed platform. Nor will a downloadable spreadsheet restore the automations, permissions and connections that run the business. The question is not only whether the service comes back. It is whether customers can continue without it.
A SaaS startup may begin with a narrow tool for payments, inventory, identity checks or customer records. As customers connect more systems and build more workflows around it, replacing the service becomes progressively harder. What started as a vendor becomes part of the customer’s operating infrastructure, without necessarily acquiring the obligations associated with that importance.
That is a market failure in the making. The founder receives recurring revenue from customer dependence, while the largest cost of an abrupt collapse may fall on businesses that never had a say in the provider’s financing or survival.
To be clear, Synapse and CDK had different causes and consequences. Neither proves that every small SaaS vendor presents systemic risk. They prove that organisational size is a poor substitute for measuring operational dependence.
Regulators have begun responding in finance. In November 2024, the Bank of England, Prudential Regulation Authority and Financial Conduct Authority published final rules for designated critical third parties. The framework recognises that disruption at a technology supplier can threaten financial stability even when the supplier is not itself a bank.
But the principle should not end at the financial sector. Why should a hospital, logistics network or large group of retailers be expected to discover only after an outage that one privately run application is a single point of failure?
I would propose a Critical Software Dependency Test, not a new licence for every startup.
The test would ask how many essential operations rely on a provider, how concentrated that dependence is, and how long customers would need to recover if the provider stopped trading. It should look beyond uptime figures to data recoverability, the portability of live workflows and the existence of workable alternatives.
A vendor crossing a clear impact threshold should face proportionate duties: tested backups, an independently reviewed exit plan, advance notice of major service changes where possible, and a practical means for customers to retrieve the records necessary to continue operating. For particularly consequential services, customers could contract for escrow or continuity arrangements.
There is a reasonable objection. Such requirements could burden young companies, raise entry costs and favour well-funded incumbents. Imposing bank-level compliance on a small scheduling application would be absurd.
That is precisely why obligations should follow dependency and potential harm, not valuation or headcount. A startup serving ten customers whose operations can easily move elsewhere should not be treated like one holding the only usable records for an entire network.
Customers have responsibilities too. A business that never tests an export, documents a fallback or asks what happens if its vendor becomes insolvent is taking a risk it should understand.
Founders should see this not only as an obligation but as a competitive opportunity. Demonstrable recovery and exit rights could become reasons to buy from a smaller provider rather than default to a familiar name.
The technology industry has spent years asking which startup might become worth a billion dollars. It should also ask which startup could cause a billion dollars of disruption if it failed.
The next too-big-to-fail company may not look big at all. That is exactly why we need to recognise it before something breaks.
About the Author
Helal Chowdhury is a digital technology entrepreneur and product growth leader with experience in SaaS, proprietary software products and technology commercialisation. His interests include software resilience, digital infrastructure, product economics and the responsibilities of businesses delivering critical technology services.