The Last Subscription You'll Ever Buy

Anthropic has launched Fable 5.

On its own, that sentence is the kind of thing that causes a brief ripple of interest among people who follow AI model releases, a slightly longer ripple among developers, and approximately no ripple at all among the 99% of the economy that runs on spreadsheets and a prayer. A new AI model launches with roughly the same frequency as a new cryptocurrency, and most of them share a similar trajectory: loud announcement, benchmark wars, gradual absorption into the background hum of things that were supposed to change everything.

But I think Fable 5 might be different. Not because of its architecture, or its context window, or whichever number it has beaten on whichever leaderboard. Different because of what it can do with code, and more specifically, what it enables people who are not developers to do with code. We may have crossed a threshold that has been approaching for several years, quietly, without anyone marking the moment with the appropriate amount of ceremony.

The threshold in question is this: the effort required to build a custom software application has dropped below the effort required to adopt, configure, train staff on, integrate, and maintain a SaaS one.

 

The SaaS Bargain, and Why It Has Always Been a Compromise

The SaaS model became dominant for good reasons, and not just because I was there inventing/architecting the very first one! Software is hard to build, hard to maintain, and hard to secure. Anyone creating the World's first SaaS, building ActiveX controls to launch Citrix apps from a html launch page knows this. The economics worked: a vendor builds the thing once, spreads the cost across thousands of customers, and everyone gets a polished product at a price no individual customer could justify for bespoke development. The customer pays a monthly subscription and, in exchange, gets software that mostly does what they need, in the way someone else decided it should be done, at a pace of improvement determined by a product roadmap they had no part in writing.

That last part is the compromise. SaaS is general-purpose by design. It has to be. A project management tool serving fifty thousand businesses cannot afford to be opinionated about any one of them. So it grows features until it is comprehensive, which is the product management equivalent of saying it grows features until it is exhausting. Every SaaS product eventually becomes a small city: impressive from the air, bewildering to navigate on foot, and containing at least three districts that nobody who works there has visited in years.

The small business owner using a professional services automation tool to manage five employees and twelve clients does not need the enterprise tier feature set. They need something that fits their specific workflow, talks to their specific other systems, and does not require a two-day onboarding with a customer success manager who will never quite understand that they invoice weekly, not monthly, because that is how their clients prefer it.

For twenty years, the answer to this problem was: cope. The SaaS product is the SaaS product. Configure what you can configure. Work around what you cannot. Or pay a developer something in the low five figures to build something bespoke, which takes six months, requires ongoing maintenance, and will be held together by whatever the developer was using as a framework the year they built it.

 

Vibe-Coding Was the Early Signal

Vibe-coding, if you have managed to avoid the term, is the practice of using AI to write code through natural language instruction, often by someone who is not a developer and does not particularly intend to become one. You describe what you want, the AI builds it, you iterate through conversation until it does what you need. The name is slightly embarrassing but the underlying capability is not.

The early versions of this were impressive in the way that a dog walking on its hind legs is impressive: not that it was done well, but that it was done at all. The output was plausible-looking code that worked until it did not, required constant intervention, and had the structural integrity of a sandcastle built by someone in a hurry. Useful for prototypes. Inadvisable for anything load-bearing.

Each model generation has moved the needle on this. The code has got better. The reasoning about architecture has got better. The ability to maintain consistency across a codebase, to handle edge cases, to think ahead about what breaks when you change something, to produce output that a competent developer would not immediately want to set on fire: all of these have improved with each iteration.

Fable 5 appears to represent a step change rather than an incremental improvement. The reports coming back from developers who have used it on complex tasks describe something that feels qualitatively different. Not just faster, not just more accurate, but more architecturally coherent. It reasons about the problem before it reaches for the keyboard, which is a habit so many human developers have yet to acquire.

 

What This Does to the SME Calculation

Consider a business with twenty people. A recruitment agency, perhaps, or a specialist manufacturer, or a professional services firm of some kind. They have accumulated, over the years, a collection of SaaS subscriptions that together cost somewhere between two and five thousand pounds a month. Each one was adopted to solve a specific problem. Most of them now partially solve that problem while introducing several new ones, primarily involving data that lives in four different places and refuses to agree with itself.

With a model like Fable 5, a moderately technically literate person at that business, which is to say someone who can write a formula in a spreadsheet and is not frightened of a terminal window, can now build functional, custom software. Not in six months. Not for five figures. In days, iterating through conversation with an AI that understands their specific workflow because they described it, not because a product manager in San Francisco made an educated guess about it.

The application they build will not have a mobile app for Android, a Salesforce integration, or a compliance certification for the German market. It will have exactly the features they need, structured exactly the way their business runs, and it will cost the price of an AI subscription rather than the price of a development agency.

The SaaS vendor, watching this happen, faces a problem that is structurally familiar from other industries but no less uncomfortable for that. Their value proposition was always partly the software and partly the impossibility of building the alternative. The impossibility is diminishing. The software alone has to carry the weight.

 

The ISV Problem Is Not the Same as the SaaS Problem

It is worth separating two things that often get conflated in conversations about AI disrupting software.

SaaS vendors selling horizontal tools to SMEs: these face real and near-term disruption. The project management tool, the CRM for the small business, the invoicing platform, the basic HR system. These have always been somewhat uncomfortable compromises, and the alternative has just become dramatically more accessible.

Independent software vendors building deep vertical software: the picture here is more complicated. The ERP system for a specialist manufacturer, the case management software for a law firm with fifty years of process baked into it, the clinical records system that has to comply with regulations written by people who have never met a developer: these are not going to be vibe-coded away by a technically literate office manager in a weekend.

The complexity of these systems is not primarily about the code. It is about the domain knowledge embedded in every design decision, the regulatory requirements that constrain every data model, the integration surface with legacy systems that predate the application itself. A model that can write excellent code does not automatically understand medical device regulations, or the specific requirements of a particular financial reporting standard, or why the workflow in this department is structured the way it is because of a decision made in 2003 that nobody wrote down.

ISVs in deep verticals have a defensible moat. Not an impregnable one. But a real one. ISVs selling horizontal tools to people who just want software that fits their business: considerably less defensible.

 

The Ripples Reach Academia

This one tends to get overlooked in the technology press, which is largely written by people whose mental model of the economy stops at the office park.

Universities and research institutions have always had a complex relationship with software. They produce enormous quantities of data and have, historically, had access to people who can write code. What they have not had is those people's time, or continuity. The research software landscape is a museum of half-finished tools, scripts that worked once on a specific version of Python in a specific environment, and pipelines that are only understood by a PhD student who left for industry two years ago and has not replied to emails since.

Fable 5 level capability changes this. A researcher who can describe what their data looks like and what they want to do with it can now produce functional analysis pipelines, visualisation tools, and data management systems that are actually maintained, because maintaining them is now a conversation rather than a project. The barrier between having an analytical idea and having working software to execute it has compressed dramatically.

The downstream effects on academic software procurement are interesting. The institutional licence for the statistical analysis package that costs the university forty thousand pounds a year and is used by twelve people who only need three of its features: that conversation is going to get harder to have. Not impossible. There are network effects in academic software, citation norms, peer expectations, and the quiet conservatism of institutions that have been doing things a particular way for a long time. But harder.

More significantly, the ability to produce research software quickly changes what research is feasible. Ideas that were previously impractical because the software engineering cost exceeded the research value can now be tested. The minimum viable experiment has a lower floor.

 

The Counterargument Deserves a Hearing

The counterargument is not stupid, so it should be treated with the respect of being stated clearly before it is challenged.

Vibe-coded software, the argument goes, is software without adequate security review, without proper testing, without architectural foresight, without documentation, and without anyone who truly understands it. It will work until it does not, and when it does not, there will be nobody to call. The SME that replaced its CRM with something an office manager built on a Saturday afternoon will discover, on a Tuesday in February, that the database has been silently corrupting records for three months and there is no audit trail and no rollback.

This is a real risk. It is not a fatal objection.

The SaaS alternative also has security vulnerabilities, also fails unexpectedly, and also produces situations where nobody can explain why the data looks the way it does. The difference is that when the SaaS vendor's system fails, there is someone to call, and that call will be answered by a support tier that will open a ticket and respond within four business hours. Whether this is worth the subscription price is a question that every business that has opened a support ticket already knows the answer to.

The more honest version of the counterargument is about accumulation. One vibe-coded tool, built carefully, is manageable. A business that has replaced all of its SaaS with custom-built applications over three years has a maintenance burden that grows with each addition and is entirely dependent on the continued availability and capability of the AI model it used to build them. This is a genuine long-term risk that deserves serious consideration, and most people doing the building are not yet considering it.

 

What Happens Next

The SaaS industry will not collapse. That would require a tidiness that markets rarely supply. What will happen is margin compression, customer loss in the most contested segments, and a gradual repositioning of value propositions toward the things that AI-assisted custom development cannot easily replicate: network effects, compliance infrastructure, deep integrations, and the specific gravity of being the thing that everyone in an industry already uses.

The winners in this transition will be the businesses that understand quickly which of their competitors are SaaS vendors and which are infrastructure. SaaS vendors for SMEs in horizontal categories are under real pressure. Infrastructure vendors, compliance platforms, and deep vertical specialists are not, or at least not yet, and not from this particular direction.

For SMEs themselves, the opportunity is genuine. The ability to build software that actually fits how you work, without a six-month development project and a five-figure invoice, is not a marginal improvement. It is a structural change in what is possible for businesses that have always been forced to adapt themselves to their software rather than the other way around.

And for academia: the research that does not get done because the software engineering cost is too high is a loss that nobody has measured, because unmeasured losses have a way of going unnoticed. Some of it will now get done. That is not nothing.

Fable 5 is a language model. It does not know your business, cannot replace your judgment, and will produce code that requires oversight from someone who understands what they are asking it to build. But it is also, quietly, the moment the economics of custom software changed for a significant portion of the economy that has never previously been in the conversation.

The ceremony it deserved was probably something more than a benchmark announcement. But that is how these things tend to go.

All Posts