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

      Before substituting SaaS subscriptions with internally developed AI software, executives should assess the complete lifecycle cost of ownership rather than concentrating solely on development expenses.

      The central inquiry isn't whether the organization can create a tool, but rather if it possesses the capability and resilience to sustain, secure, and continuously adapt it over time. This assessment includes determining who will manage the system in the long run, how knowledge will be shared to prevent critical reliance on specific individuals, and if the organization is ready to take on the operational responsibilities currently managed by SaaS vendors.

      Recently, a team of journalists from CNBC utilized AI coding tools to replicate the fundamental features of the project management platform Monday.com in just one weekend.

      This led to a significant decline in the company’s stock price, sparked discussions about an impending ‘SaaSpocalypse,’ and raised an uncomfortable question in boardrooms worldwide: if software can be rebuilt so swiftly, what exactly are companies paying for when they subscribe to SaaS?

      Building software has become significantly cheaper. Internal tools that once required extensive development time, specialized teams, and substantial budgets can now be created in just days. Initiatives that previously necessitated structured engineering processes can sometimes be pieced together over a weekend, if not quicker.

      This transformation is now apparent in purchasing decisions. CIOs, CEOs, and CFOs are reevaluating existing SaaS contracts as well as those under negotiation. If software can be recreated internally at a fraction of the historic cost, subscription fees start to seem less obligatory. The question becomes straightforward: if we can build it, why continue paying for it?

      However, this question is incomplete. It perceives software as a final product, which it is not. Software is something that must be operated. Security updates come in continuously. Integrations can fail without warning. Regulations change. Internal processes adapt. User preferences shift.

      None of this is unusual behavior; it is part of the normal operation. In fact, the true expense of software comes after deployment, rather than before.

      Software typically spends most of its lifespan being maintained, not developed. The effort needed to keep it stable, secure, and in line with business needs is where most of the ongoing work accumulates. Although AI has increased the speed at which software can be developed, it has not diminished the obligation to keep it functional.

      This is where SaaS and internal systems part ways. SaaS providers spread maintenance, upgrades, and support across a multitude of customers, effectively incorporating that burden into their service. When organizations replace SaaS with internal systems, these responsibilities do not vanish; they are taken on internally, concentrating within a single organization, often while the company exchanges its previous subscription costs for new expenses to cover enterprise AI developer tools.

      What may appear as savings at the point of purchase can turn into an operational burden that reveals itself later, once it becomes ingrained in teams and processes. Moreover, it rarely becomes stable. Software must adapt because everything around it does. Each change introduces further work: fixes, updates, testing, and integration modifications. It requires clear ownership.

      A secondary cost arises in conjunction with this. Every system necessitates ownership. In a SaaS scenario, that ownership lies with the vendor. In internal builds, it shifts to the organization. Responsibilities regarding roadmaps, incidents, support, and ongoing development often consolidate with a small group of individuals who have an in-depth understanding of the system.

      This creates a different type of dependency. Companies may believe they are eliminating vendor lock-in, but in reality, they may be replacing it with reliance on specific individuals. This is often a more unfavorable exchange.

      With AI facilitating faster development, the risks also escalate. Systems come together more rapidly, but tend to have less shared documentation and fewer stable reference points. If the individuals who constructed these systems depart, what remains is software that is more challenging to interpret, modify, and may prove to be more fragile than anticipated. The dependency hasn't vanished; it has just shifted.

      Thus, the decision to build versus buy is not merely a cost analysis. It involves determining where operational accountability should reside and how much complexity an organization is willing to manage over time.

      Prior to switching from SaaS to internal software, executives must look beyond the initial development. They must consider what follows: maintenance, integration, security, continuity, and staff turnover.

      The takeaway is not that organizations should refrain from building software internally; in many cases, they indeed should. AI has sufficiently altered the economic factors to make this feasible in situations where it previously seemed impractical. However, it has only impacted one aspect of the equation.

      While it has reduced the costs associated with building software, it has not lowered the costs required to run it. This gap is where many enterprise decisions may falter.

      Thus, before terminating the next SaaS subscription, the question is straightforward: it is not whether it can be reconstructed, but whether the organization is ready to assume all the subsequent responsibilities.