Why SaaS Was Never Really the Problem

The Shift

It is easy to tell the story of AI and software as though the old model got everything wrong.

SaaS standardized organizations. SaaS forced teams into generic workflows. SaaS created lock-in, disconnected data, and bloated software stacks. Therefore, the story goes, AI will liberate everyone from it.

That story is neat, but it misses something important: SaaS solved real problems.

For most organizations, buying software instead of building it was an extraordinarily sensible decision. It gave them capabilities that would have been prohibitively expensive to create and support on their own. It made payroll, customer support, financial management, collaboration, security, and countless other functions available without requiring each company to become a software company.

The fact that AI changes some of those economics does not mean the prior choices were mistakes. It means the tradeoffs are changing.

That distinction matters because it leads to a more useful question than “What will replace SaaS?” The better question is: which decisions should remain standardized, and which can now be shaped more directly around how an organization works?

The bargain SaaS offered

SaaS turned software from a capital-intensive project into an operating expense. Instead of funding a long implementation and then carrying the burden of maintenance indefinitely, an organization could adopt a product that already worked for many of the same jobs.

That bargain included more than features.

It included ongoing improvements, security practices, uptime, integrations, user support, a hiring market for experienced administrators, and a community of peers who had encountered similar problems. Standardization did not just reduce development cost. It reduced the number of decisions an organization had to make for itself.

That was often a feature, not a flaw.

Most companies do not need a distinctive way to manage expense reports. Most do not gain an advantage from inventing their own identity system or maintaining a bespoke video-conferencing platform. Even in areas that matter deeply to the business, standardizing some underlying capability can free attention for work that is more differentiating.

SaaS also gave organizations a shared language. When a team adopted a mature platform, it adopted conventions that were legible to new employees, consultants, and integration partners. The software imposed constraints, but those constraints could make coordination easier.

None of this disappears because AI can generate a convincing application.

Where the bargain became costly

The limitations of SaaS came from the same source as its benefits: a product designed for many organizations cannot fully reflect the operating logic of any one organization.

That mismatch is not always a problem. It becomes one when the parts that do not fit are the parts that carry meaningful knowledge about how the business operates.

An organization might have a distinctive way of qualifying an opportunity, resolving an exception, coordinating a service handoff, or assessing risk. A standard platform may have a workable approximation. The question is whether the approximation is good enough, whether the cost of adapting is acceptable, and whether the organization even notices what it has given up.

For years, the answer was often straightforward: preserve the distinction only if it is worth the expense of custom development, integration, maintenance, and future upgrades.

That threshold was high. So organizations made sensible compromises.

They configured what they could. They handled the rest in spreadsheets, email, meetings, or the judgment of experienced people. They sometimes changed the process to fit the available system. Over time, a tool chosen to support the work could begin to shape what work seemed possible.

This is not an indictment of the teams making those choices. It is what rational optimization looks like under a real constraint.

AI changes the threshold, not the need for judgment

AI lowers the cost of expressing and testing system behavior. A team can model a specific workflow, generate an interface, define an agent’s role, create an automation, connect to an existing system, and learn from a working prototype much faster than it could before.

That expands the range of things worth shaping around the organization.

It does not mean that every bespoke workflow is suddenly wise. A fast-generated solution still needs reliable data, appropriate access controls, clear ownership, support, and a reason to exist. The cost of generating a first version is not the full cost of operating a system.

But the threshold has moved.

Previously, a team might accept a poor fit because the alternative required a multi-quarter project. Now it may be able to explore the alternative in days. Previously, a useful local workflow, report definition, or agent instruction might have remained a fragile spreadsheet, note, or personal practice because formalizing it was too expensive. Now the team can make it visible, test it, and decide whether it deserves to become a more durable part of the operating model.

The new opportunity is not to abandon standard software. It is to make more deliberate choices at the boundary between the standard and the specific—whether the resulting capability is a platform configuration, an automation, an agent, or a report.

Use a standard product when the standard is genuinely useful. Build or adapt when a local distinction is important enough to carry forward. Connect the two where that is the most practical answer.

That is a more interesting future than a wholesale replacement story. It is a future of composable systems, where organizations can rely on shared platforms without surrendering every part of their own model of how work should happen.

The risk of reacting too far in the other direction

There is an equal and opposite mistake available now: treating every existing constraint as proof that an organization needs custom software.

Some constraints are healthy. A standardized process may reduce variation that does not create value. A shared data model may make reporting and coordination possible. A platform boundary may prevent a team from creating a solution that only one person understands and no one else can support.

The point is not to make the software mirror every habit an organization has accumulated. Organizations contain accidental complexity too. Old workarounds can persist long after the problem that created them has gone away. A new tool can be an opportunity to question those habits rather than encode them permanently.

This is why the work cannot begin with a demand for customization. It has to begin with understanding.

Before deciding whether a process should be standardized, adapted, or rebuilt, a team needs to understand what the process is accomplishing, where it creates friction, which distinctions matter, and whose perspective is missing. Without that work, AI simply makes it easier to automate the first plausible interpretation.

A more useful relationship with software

The best outcome is not that organizations reject SaaS. It is that they regain the ability to use it more intentionally.

They can treat a platform as a useful component rather than as the complete definition of their operating model. They can preserve their most important knowledge outside the limits of any single vendor’s object model. They can develop a clearer understanding of what is standard by choice, what is specific by necessity, and what has not yet been examined closely enough to decide.

This also changes the role of internal technology teams and consultants. Their work is less about translating a fixed business request into a fixed software configuration. It is more about helping the organization make the meaningful choices visible: what should change, what should endure, and what needs to be understood before a decision is encoded in a system.

SaaS was never really the problem. The problem was having so little practical ability to distinguish between the ways an organization needed to adapt and the ways its software could adapt instead.

AI gives organizations more room to make that distinction. It also gives them more responsibility for making it well.

That raises the next question: what happens when an organization gains more choices than it has shared understanding to use?