A Trello clone is not Trello. It does not have Trello’s permission system, enterprise controls, mobile apps, notification settings, automations, integrations, templates, admin screens, marketplace, support team, uptime commitments, billing infrastructure, or fifteen years of product decisions hidden in small corners of the interface. But it can have columns, cards, drag and drop, local state, and an export button. For many personal workflows, that is enough. And “enough” is the part SaaS should worry about.
The same is true for writing tools. A rewritable document is not Microsoft Word. It does not reproduce the full Office stack, enterprise collaboration, track changes, template libraries, compatibility modes, policy controls, or decades of accumulated document weirdness. But it can be a writing surface, carry its own data, expose its own editing interface, and change itself when asked. Again, enough.
That is the actual shift. Not that one person can rebuild Trello. Not that a local document replaces Word. The shift is that the useful slice of a software product can now be separated from the product around it. The workflow no longer has to arrive bundled with an account, a vendor, a pricing page, a roadmap, and someone else’s storage.
Users are not replacing SaaS wholesale
The current build-your-own-software wave is real. It is no longer just developers using better autocomplete. Lovable says four in five of its users identify with non-technical roles. Founders, freelancers, product people, operations teams, marketers, consultants, salespeople, designers, and finance or admin workers are building software directly. Business Insider reported that Lovable passed $500 million in annual recurring revenue and that most users come from non-engineering backgrounds.
That is not a small signal. Software creation is moving closer to the people who actually feel the workflow problem. But it is easy to overstate what follows from that.
While users are building more software, it does not mean they are replacing SaaS in the way people usually mean it. They are not casually rebuilding Salesforce, Workday, SAP, ServiceNow, Microsoft 365, or Snowflake with a few prompts and a weekend of enthusiasm. The systems that run large companies are not just screens and forms. They are permissions, integrations, compliance, audit trails, support obligations, shared data models, procurement histories, migration paths, and risk transfer.
Users are building more software
Because users are building more software in the first place, the Klarna story became such a bad shortcut. The simplified version was that Klarna had dropped Salesforce and Workday and replaced SaaS with AI. But Klarna did something different. It reduced and reworked parts of its SaaS stack, but even its CEO later pushed back against the idea that other companies should read this as a general recipe for replacing Salesforce with AI.
The same pattern shows up everywhere in the build-your-own story. The actual replacement happens first where the tool is small, local, personal, internal, or annoying enough that “good enough” beats “complete.”
A private task board. A simple project tracker. A lightweight CRM for one sales motion. A dashboard for one recurring report. A form around a spreadsheet. A calculator with a nicer face. A tiny workflow that used to justify another monthly subscription. That is where SaaS is exposed - not at the center, but at the edges.
SaaS sold a lot of “too much”
SaaS won because custom software was expensive. If a team needed a workflow tool, the realistic choice was not “buy SaaS or build exactly what we need.” It was “buy SaaS or do nothing.” The subscription was cheaper than an internal project. The generic product was easier than specifications, development, hosting, updates, and maintenance.
That bargain created an enormous market for software that was often larger than the user’s actual need. You subscribed to a product because you needed five percent of it. You adapted your work to its model. You accepted the extra features as the cost of not building. You accepted the account because the interface lived in the vendor’s system. You accepted the data model because that was where the workflow lived.
AI app builders attack exactly this bargain. They do not need to beat mature SaaS products feature by feature. No, they only need to make the useful five percent cheap enough to build.
That is why feature parity is the wrong test. A personal Trello clone does not fail because it lacks enterprise administration. It only fails if the person using it needed enterprise administration. A local writing tool does not fail because it is not Word. It fails only if the missing parts were the parts that mattered.
The rent did not disappear
But there is a catch. Most of the current build-your-own wave does not bring software home. It moves the software from one rented system into another rented stack. A generated app still needs somewhere to run. It needs a database, storage, authentication, hosting, model calls, logging, deployment, and sometimes payments, email, file handling, or integrations. The old subscription may disappear, but a new pile of usage meters appears underneath it.
The user stops paying for a finished SaaS product and starts paying for the ingredient and the rent moved from the seat to the stack. It moved from the application to the infrastructure, from the product plan to credits, hosting, auth, databases, and inference.
That is not a small difference. The new tool may fit better. It may be cheaper, it may be faster to change and it may be closer to the work. It may remove the strange mismatch between a generic SaaS product and a specific workflow. But the runtime still belongs to someone else, the database is elsewhere and the model is elsewhere. The deployment is elsewhere and of course you need an account. And - most importantly - the meter is still running. This is why most of today’s “post-SaaS” story is not really post-SaaS. I think it is SaaS unbundled: instead of one vendor owning the whole product, several vendors own the layers.
The market noticed the threat
Investors have started to price this problem. In February 2026, Forrester described a major software selloff as a reaction to AI agents and the fear that software workflows themselves were being repriced. The panic was not that people had stopped needing software. It was that the old SaaS growth story looked less secure if agents could perform work across tools, generate small applications, and reduce the value of seats. That panic later softened and software stocks rebounded. SaaS was not dead after all: in 2026 SaaS simply felt pressure from the long tail.
The incumbent answer is already visible. All SaaS products have become agentic with lighter interfaces and workflows moving into an AI layer. Pricing shifts away from simple seats toward usage, automation, or outcomes. SaaS vendors try to remain the place where the work happens, even if the user no longer clicks through the old screens.
But it preserves the same basic arrangement, only the application changes its shape and the rent remains. After all: the AI tier is still a tier in a SaaS solution and the agent still runs somewhere. The workflow still depends on a provider where the data still sits in the system built to meter it.
The local version is different
The more interesting question is not whether AI kills SaaS. The question is which parts of SaaS never needed to be SaaS in the first place. A file can hold data. A browser can render an interface. A local model can help change the file. A small application can live as an artifact instead of a service. The user can open it, use it, modify it, copy it, back it up, and move it without asking a vendor. That is the version the current market debate mostly ignores.
The mainstream AI-builder story still assumes a hosted runtime. The local-first version asks what happens when the artifact owns more of the stack. Not just the content, but the interface. Not just the interface, but the editing mechanism. Not just the editing mechanism, but the ability to change without going back through a cloud product.
That does not make it enterprise software. It does not solve compliance, synchronization, identity, multi-user permissions, backups, or security by magic. It does not mean every workflow should become a local file. But it changes the maintenance question for small software.
The strongest defense of SaaS is maintenance
The build-your-own story has an obvious weakness: software does not end when it starts working. It breaks. Requirements change. Edge cases appear. Data formats drift. Users do unexpected things. Security problems hide in the parts nobody looked at. A tool that was impressive as a demo can become dangerous as infrastructure.
The risk is already visible. Axios reported that vibe-coded apps built with tools such as Lovable, Replit, Base44, and Netlify had exposed hundreds of thousands of public assets, including thousands containing sensitive corporate information. That is not an argument against AI app builders. It is an argument against pretending that creation and operation are the same thing.
SaaS on the other hand, bundles maintenance into the subscription. That is part of what the user pays for. The vendor hosts, patches, monitors, secures, documents, updates, supports, and absorbs some of the blame when things go wrong.
A local-first stack has to answer that. It cannot just say “the user owns the file” and ignore the cost of ownership which without maintenance is just responsibility. While that is not enough for payroll system in a company, it may be enough for a private board.
The Post-SaaS Scenario
A lot of SaaS is heavier than the job it performs. This is easiest to see in personal and small-team software. A task board, a writing surface, a planning tool, a tracker, a dashboard, a lightweight CRM, a project notebook, a research database, a quote calculator, a status page. These are often not “applications” in the grand sense. They are structured documents with behavior. That made sense when the alternative was no tool at all. It makes less sense when the alternative is a file that behaves like the part of the product the user actually needed.
The first AI software wave proved that people will build their own tools when the threshold gets low enough. The next question is whether they will want to own them. Not all of them. Not the big systems. Not the regulated cores. Not the shared operational machinery of large companies. But the small tools, the personal workflows, the internal utilities, the half-products that were only SaaS because SaaS was the easiest way to distribute an interface and store some data.
The post-SaaS local stack is not here as mass behavior. The hosted builders are winning because they are easier. The cloud remains the default because accounts, sync, sharing, storage, and deployment are convenient. Local models are improving, but the tooling around them is still awkward, although it's quickly improving.
So the actual post-SaaS scenario is about the useful slice of a SaaS product which can now escape the product and end up on a local machine in a directory. A board can become a file. A writing tool can become a file. A workflow can become a file. The editing loop can stay with it and the model can run on the same machine.
People have started building their own software. What they mostly have not done yet is bring the runtime home. It's not the end of SaaS, but the end of renting the small things that never needed to be services.
Unlock the Future of Business with AI
Dive into our immersive workshops and equip your team with the tools and knowledge to lead in the AI era.