The end of standard SaaS, the rise of software shaped by the organization

Generic SaaS held for twenty years. It is about to give way to something else. Not a return to the on-premise model of the 2000s, not a new public-cloud cycle, but a deeper shift: software stops asking the organization to adapt to it. The opposite happens. Software becomes the executable writing of business reality, and that reality has no reason to be identical from one organization to the next.

Why generic SaaS is reaching the end of the line

The founding bet of SaaS, formulated between 2005 and 2015, came in three propositions. Pool infrastructure costs across thousands of customers. Standardize processes so all benefit from best practices codified in the product. Outsource maintenance to free IT departments from plumbing. Of these three, two have become commodities, and the third is now turning against the vendors.

Infrastructure no longer costs anything. AWS, GCP and Azure made trivial what required ten engineers twenty years ago. Standardization, in turn, has become the main problem of large organizations. When SAP, Salesforce or Workday impose their data model and their processes, the company pays a continuous adaptation debt. Each business exception becomes a costly configuration project. Each evolution of the SaaS forces another touch-up of the workaround. And outsourcing maintenance translates, from the user's point of view, into a product that changes without their consent, that adds features they didn't ask for and removes the ones they use.

The total cost of ownership of standard SaaS, accounted for honestly, often exceeds that of well-built bespoke software. The difference is that it is invisible. It is called adaptation debt, productivity loss, business-team frustration, breaking Zapier integrations. Taken individually, each of these line items is minor. Combined, they represent half the value SaaS claimed to bring.

What makes the return of bespoke software possible

Bespoke was never abandoned because it had no value. It was abandoned because it cost too much to produce and too much to maintain. It is precisely that equation that flipped between 2023 and 2026.

• AI-assisted generation divides the cost of producing code by five to ten, and lets business profiles actively participate in product design.
• Event-sourced architectures and the DDD metamodel offer the kind of long-term stability that was impossible with the bespoke architectures of the 2000s.
• Standard protocols like MCP make business bricks interoperable, eliminating the risk of permanent reinvention.
• Governed AI agents make it possible to automate evolutionary maintenance without rebuilding a vendor team in-house.

The consequence is mechanical. The cost of bespoke becomes comparable to that of standard SaaS. Its value, on the other hand, is radically higher. Because bespoke encodes what standardization erases: the actual business expertise, the organizational specifics, the specific frictions the team wants to remove.

Encoding actual business expertise, not the market average

Business expertise cannot be reduced to a standard workflow. An M&A boutique law firm doesn't have the same friction points as a labour-law firm. An industrial SME producing one-off parts doesn't have the same constraints as a series-production SME. A community hospital doesn't follow the same patient pathways as a teaching hospital. Standard SaaS, by construction, optimizes for the average case. It penalizes the special cases, which are precisely the ones that have a reason to exist.

Encoding actual expertise means modelling in the software the concepts experts manipulate daily, with their precise definitions and their evolution rules. Not an approximation. Not a translation into a generic model. The exact concept, with its exact terminology, its invariants, its state transitions. That's what the DDD community calls the ubiquitous language: a vocabulary shared between business experts and code, with no semantic slippage.

This ambition, technical in appearance, is in fact organizational. It assumes that business experts participate in defining the model. It assumes that the software evolves as the business understanding evolves. It assumes that the translation debt between business and code is brought to zero, or as close to zero as possible. No standard SaaS can reach that level, because its economic value comes precisely from the opposite: a frozen model, sold identical to thousands of customers.

Erasing frictions, not displacing them

A friction is a place where the actual work meets a software constraint. A required field that doesn't make sense in some cases. A validation step that slows things down without validating anything. A rigid workflow that forces workarounds. Data entered twice because two tools don't talk to each other. A legitimate exception that requires a support ticket every time.

Frictions are not bugs, they are gaps between the organization as it is and the organization as the software assumes it. In standard SaaS, you cannot erase them, because the software does not know they exist: it was designed for the average case, not for the local situation. At best you can work around them, which creates other frictions elsewhere.

Bespoke makes it possible to look at each friction and decide: do we keep this constraint because it protects something, or do we erase it because it slows things down for nothing? The very question is forbidden in a SaaS, which imposes constraints by default without saying why. Bespoke makes the question possible, and therefore makes optimization possible.

Designing the organization with a software lens

On a three-to-five-year horizon, the deepest shift will not be the arrival of new tools. It will be a change in how leaders conceive their organization. Today, you first draw the org chart, define the processes, and then choose software that supports them more or less well. Tomorrow, the organization and its software will be designed together, as two faces of the same artefact.

This idea is not new. Conway formulated it in 1968 in inverse form: the structure of software systems reflects the structure of the organizations that design them. What changes in 2026 is that the formulation becomes bidirectional. Organizational structure can now be designed taking into account the affordances software makes possible. A workflow, an authorization, a responsibility, a decision loop: all these organizational objects become negotiable, because the software that supports them is itself negotiable.

Concretely, this means that a leader thinking about a new business line will no longer ask IT what software exists to support it. They will describe the business line as they conceive it, and the software will be built from that description. If the organization evolves, the description evolves, and the software evolves with it. Software stops being legacy infrastructure and becomes a living material, in the image of the organizations it serves.

What this concretely changes for executives

The first signal of the shift is already visible in advanced finance and operations leadership. They are stopping paying licences for features they only use 30% of. They are stopping engaging integrators to make their eight SaaS tools talk to each other. They are stopping reproducing in Excel calculations their ERP can't perform. They are outsourcing the thinking on their software to partners who build it from their actual business.

This movement is not ideological, it is economic. The return on investment of bespoke software, calculated honestly over five years, exceeds that of standard SaaS for most organizations whose business is differentiated. The condition is that the bespoke be built with an architecture that survives over time, that evolves by configuration rather than by rewrite, and that produces audit evidence natively. That is exactly what modern event-sourced frameworks make possible, and what organizations were buying at a loss from SaaS vendors for twenty years.