Is the ‘SaaSpocalypse’ just a myth? The actual expenses of AI-generated software.

      Before substituting SaaS subscriptions with internally developed AI software, executives need to assess the entire lifecycle cost of ownership rather than just the development expense. The crucial inquiry is not about the organization’s ability to create a tool, but whether it has the capacity and resilience to maintain, secure, and evolve it consistently over time. This entails examining who will have long-term ownership of the system, how knowledge will be shared to prevent critical dependencies on specific individuals, and whether the organization is ready to take on the operational responsibilities currently managed by SaaS providers.

      A few weeks ago, a group of journalists from CNBC utilized AI coding tools to replicate the core features of the project management platform Monday.com in just one weekend. This resulted in a significant decline in the company’s stock price, sparked discussions about an impending ‘SaaSpocalypse,’ and raised a challenging question in boardrooms worldwide: if software can be recreated so quickly, what are companies truly paying for when they opt for SaaS?

      The cost to develop software has decreased significantly. Internal tools that previously took months of development, specialized teams, and considerable budgets can now be created within days. What once required a structured engineering approach can, in some instances, be pieced together over a weekend, or even less. This shift is now reflected in procurement choices. CIOs, CEOs, and CFOs are reexamining existing SaaS contracts and those in the negotiation stage. If software can be rebuilt internally at a fraction of historical costs, the justification for subscriptions becomes less certain. The blunt question emerges: if we can create it ourselves, why continue to pay for it?

      However, this perspective is incomplete. It views software as a finished product, which it is not. Software needs to be operated. Security updates are ongoing. Integrations can fail unexpectedly. Regulations change. Internal workflows develop. Users' needs evolve. None of these scenarios are exceptions; they are part of the system's nature.

      Typically, the real cost of software arises after deployment, not beforehand. Most of a software’s lifecycle is spent on maintenance, as opposed to initial writing. The effort required to keep software stable, secure, and aligned with business goals accumulates over time. Although AI has accelerated software production, it has not diminished the burden of maintaining it operationally.

      This is where SaaS and internal solutions differ. SaaS providers distribute maintenance, upgrades, and support responsibilities across thousands of customers, embedding this burden within the product. When organizations switch from SaaS to internal systems, these responsibilities do not vanish; they are internalized and concentrated within one organization, while the company trades its previous subscription fees for new ones to afford enterprise AI development tools.

      What appears to be savings during the purchase process often manifests as an operational burden later on, when it becomes ingrained in teams and processes. Additionally, software is constantly evolving due to changes in its environment. Each alteration generates work—such as fixes, updates, testing, and integration modifications—implying that someone must manage all of it.

      Another cost arises with ownership. In SaaS, ownership lies with the vendor, while in internal builds, it transfers to the organization. Responsibilities related to roadmaps, incidents, support, and ongoing development typically become concentrated among a handful of individuals who possess in-depth knowledge of the system. This leads to a different type of dependency. Companies often believe they are eliminating vendor lock-in, but they may inadvertently replace it with dependence on specific individuals, which is often a worse situation.

      As AI accelerates development, the risk of dependency intensifies. Systems may be assembled more rapidly, yet with less comprehensive documentation and fewer lasting reference points. When the creators depart, the resulting software can be harder to understand, modify, and is often more fragile than anticipated. Thus, the dependency hasn’t vanished; it merely shifted locations.

      This underscores that the build-versus-buy decision extends beyond costs; it involves determining where operational accountability should reside and evaluating how much complexity an organization is willing to manage over time. Prior to replacing SaaS with internal software, executives must consider not only the initial build but also the subsequent demands: maintenance, integration, security, continuity, and turnover.

      The takeaway isn’t that companies should shy away from developing software internally—many are in a position to do so. AI has transformed the economics sufficiently to make internal development feasible in scenarios that previously made little sense. However, it has only altered one aspect of the equation. It has reduced the cost of building software but hasn’t made it cheaper to operate.

      This disparity is where many enterprise decisions are likely to falter. Before terminating the next SaaS subscription, the fundamental question remains: not whether the software can be recreated, but whether the organization is ready to assume responsibility for everything that follows.