The OccupySaaS movement is challenging software giants by rebuilding their platforms with AI. But what if the real revolution is to stop thinking of software as a product we have to buy?
OccupySaaS: A Rebellion Against Subscription Software
In October 2026, a movement emerged that could be an early sign of a profound shift in the software industry. Its name is OccupySaaS.
The idea is as simple as it is provocative: a collective of developers, including engineers affected by layoffs in tech, is using artificial intelligence to rebuild some of the world's most widely used enterprise software as open-source alternatives. Its first targets include Auth0 and Salesforce.
Using an approach known as a clean-room rebuild, developers start from publicly available documentation and API specifications to create independent software designed to be compatible with the original products. The goal is not to copy proprietary source code. It is to reproduce observable behavior and integration interfaces so businesses can replace expensive platforms without necessarily rewriting everything connected to them.
It's a powerful idea. But reading OccupySaaS's manifesto made me ask a question: what if we're trying to solve the right problem in the wrong way?
The Problem Isn't Just What SaaS Costs. It's That We've Become Dependent on Software.
For more than twenty years, we've built a world in which the answer to almost every business problem has been the same: buy software.
Need to manage customers? Buy a CRM. Need to organize tasks? Buy a task manager. Need to process expenses? Buy another application. Need to coordinate approvals? Find a dedicated tool.
Every new problem potentially introduces a new product, a new subscription, a new interface and another collection of data. The business ends up adapting the way it works to the software it bought, rather than the other way around.
The result is familiar: organizations running dozens of overlapping applications, with fragmented information and processes constantly crossing the boundaries between systems.
OccupySaaS proposes an important answer: open alternatives with less vendor lock-in. But even if we replace Salesforce with an open-source CRM, one fundamental question remains: why does a business necessarily need a traditional CRM in the first place? More precisely, why must it adopt an entire product to access the few capabilities it actually needs?
From Software as a Service to Software as a Need
Imagine a company that needs to organize sales visits. It needs to record appointments, collect customer information, assign tasks and analyze results.
Today, it would probably start by shopping for a CRM. Then it would configure it, customize its fields, train its people, perhaps hire a consultant and connect it to other systems.
But the company's original need was not to buy a CRM. It was to organize sales visits. Those are two very different things.
What if a company could simply describe the outcome it wants and get the process, data and interface required to achieve it? Without selecting a product from a catalog first. Without necessarily paying for every person authorized to use it. Without adopting dozens of features it will never need.
This is the shift I like to call Software as a Need rather than Software as a Service: software stops being a prepackaged product to subscribe to and becomes a capability shaped around a concrete need.
Ephemeral SaaS: Software That Exists for as Long as You Need It
This evolution introduces an even more interesting concept: ephemeral software.
For decades, we've treated software as something permanent. We buy it, configure it, maintain it and gradually try to adapt it to changing requirements. But what if we could separate the lifespan of a need from the lifespan of the application that serves it?
Imagine a company organizing a trade show. For three months, it needs to manage exhibitors, meetings, requests, authorizations and operational tasks. Once the event is over, many of those features are no longer useful.
Under the traditional model, the company may have purchased or customized software it must keep maintaining. Under an ephemeral model, it could instead create an application for that particular event, use it for the required period, and retire its temporary interface and features afterward. Relevant data and process history would remain available according to the business's needs.
Software can be temporary. The company's knowledge and data should not be.
Disposable software doesn't mean unreliable systems, lost data or having to rebuild processes every time. It means an application no longer has to be an asset preserved at all costs. It can evolve, be replaced or disappear when it is no longer useful.
Think of scaffolding used to construct a building. No one buys scaffolding intending to keep it standing forever after construction is complete. Yet that's often exactly what we do with software.
Flowvenue: One Platform, Infinite Applications
This thinking is precisely why we built Flowvenue.
We didn't want to build yet another CRM, business management system or project management application. We wanted to build something different: a platform capable of turning the description of a business need into an operational process.
With Flowvenue, users can describe what they need in natural language and build a process with their own information, rules, activities and automations. They can then work with those same processes in two complementary ways.
The first is conversational: people interact with data and operations using natural language, including through external AI assistants connected via MCP. The second is visual: the same processes can be accessed through conventional interfaces or custom applications designed for a specific use case.
Imagine three businesses. A service company builds a system to manage customer requests. A sports organization creates an application for teams, athletes, training sessions and matches. An industrial company organizes its sales activities and distributor visits.
Three completely different applications. Three different interfaces. Three different sets of rules and processes. But one underlying platform.
There's no need to develop three independent SaaS products, each with its own infrastructure, authentication and data management. Applications are modeled around the organization's actual needs. And as those needs change, the processes and interfaces can change with them.
Businesses should no longer have to fit into software. Software should take the shape of the business.
OccupySaaS Wants to Replace Salesforce. We Want to Make It Possible Not to Need Salesforce.
This is where the most interesting difference between OccupySaaS and our vision emerges.
OccupySaaS starts with an existing product and asks: how can we rebuild it, make it open, and let businesses replace the original?
We start with a different question: what problem does the business need to solve, and what is the smallest set of capabilities required to solve it?
In the first approach, the existing product remains the reference point. In the second, the business process becomes the reference point.
There's nothing wrong with the first approach. On the contrary, initiatives such as OccupySaaS can genuinely help reduce dependence on major technology vendors.
But I believe the bigger transformation will come when we stop using traditional software categories as the starting point. A business shouldn't necessarily have to choose between Salesforce and an open-source Salesforce clone. It should be able to define the sales-management capabilities it needs, build them, modify them and use them in the most natural way possible, while continuing to integrate with existing systems when required.
That doesn't mean every company should abandon its ERP, CRM or legacy platforms. It means buying another software product shouldn't be the only possible answer to a new business need.
The SaaS Business Model Needs to Change Too
There's another aspect that OccupySaaS rightly challenges: per-user pricing.
The per-seat model has been one of the cornerstones of the SaaS economy. But it creates a paradox: the more people in a company who could benefit from a tool, the more expensive it becomes to give them access.
In many organizations, this encourages limiting access to digital tools rather than expanding it. We chose a different direction.
Flowvenue uses a Pay as Grow model based on actual usage and operational consumption, tracked through BeeCoin credits. We don't sell individual user licenses. Our aim is to connect platform costs to the work actually performed, rather than to the number of people who might perform it.
Of course, usage-based costs must also be transparent and predictable. Replacing per-user pricing with unpredictable bills would hardly be progress.
But the principle stands: the value of software isn't measured by how many people can access it. It's measured by the problems it solves.
Disposable Software Doesn't Mean AI Without Guardrails
There's an important misunderstanding to avoid.
Just because AI makes it easier to create applications doesn't mean every generated application is automatically suitable for business-critical processes.
Generating an interface in a few minutes is one thing. Ensuring data consistency, enforcing permissions, preserving traceability and preventing an AI mistake from causing irreversible damage is another.
That's why I don't believe the future is simply AI agents freely writing code and changing business systems. We need platforms that separate the intelligence interpreting a request from the rules governing its execution.
That's one of Flowvenue's founding principles. AI can help define a process, understand intent and guide users through operations. But execution should take place within a structured system, with explicit rules, controls and permissions. Critical operations must remain governable, with human involvement wherever needed.
Because an application may be ephemeral. Accountability for business operations cannot be.
The Future of Software Won't Necessarily Be Another Software Product
I believe OccupySaaS is an important signal. It shows how the balance of power between those who build software and those who use it is changing.
As AI dramatically reduces development costs and makes application building more accessible, some of the historical value of prepackaged software products will inevitably come under pressure.
That doesn't mean major SaaS platforms will disappear tomorrow. Mature platforms will continue to play an essential role, especially where standardization, reliability, deep functionality and established ecosystems matter.
But something is changing. For the first time, it's becoming increasingly realistic to imagine a world where companies don't have to search for a product every time a new problem emerges. Instead, they can start with the problem and build the solution they need.
Sometimes that solution will be an application designed to last for years. Sometimes it will be a small tool used for a few weeks. And sometimes it will simply be a process accessed through a conversation, without even requiring a dedicated interface.
To me, this is the most compelling meaning of ephemeral software: not making software less important, but making ownership of a software product less important than the outcome it delivers.
OccupySaaS is demonstrating that we can rebuild the software of the giants. With Flowvenue, we're pursuing a different idea: a world where every business can build the software it needs, when it needs it, without buying a new product for every problem.
Because the future shouldn't be about choosing between a thousand applications. It should be about being able to create infinite solutions.
Flowvenue is a conversational platform for building and running business processes and custom applications with AI. Learn more at flowvenue.com.
Learn more about the movement discussed here: OccupySaaS.