Will ChatGPT Kill SaaS?

by

The public discourse has expanded beyond whether ChatGPT will kill coders to the existential threat now posed by Generative Artificial Intelligence platforms to SAAS software. According to the proponents of this narrative:

Companies will stop using SAAS and develop the required functionality with GenAI code development platforms.

This is like the good old custom development of software, just enabled by AI coding copilots like ChatGPT, GitHub Copilot, and Replit.

The major benefit of this shift is cost savings: Companies will own their AI-developed code and will no longer need to pay huge subscription fees to SAAS companies.

I call this “SaaS Repatriation“. (H/T to “Cloud Repatriation“, the trend of companies moving their workloads from cloud infra back to onprem datacenters, largely to save costs.)

SaaS Repatriation has been doing the rounds for the last 3-4 months. Going by the hammering received by SaaS company stocks during this period, Wall Street seems to have taken it seriously. The narrative blew up recently after Klarna, the Swedish BNPL provider, announced that it has shut down Salesforce and Workday and plans to develop the core functionality of these SaaS products inhouse by using AI.

When I read this news, the first question that popped up in my mind was whether it’s technically possible to replace SAAS with inhouse development.

As we say in the IT industry, anything is technically possible with custom development, so SaaS Repatriation cannot be dismissed so easily. To examine its feasibility more thoroughly, we need to trace the evolution of business software.

During the last 50-odd years, enterprise software has gone through the following paradigms:

Custom Development: Until the late-1970s, companies employed software developers to write code on programming languages to build software according to their requirements , bought servers and other infrastructure to install their software, and kept people on their rolls to run their software. Everything was done inhouse.

Commercial Off The Shelf (COTS): The late 1970s to the early 1980s saw the emergence of software products that could be used by companies off the shelf. Also known as “shrinkwrapped software”, they were initially shipped via CDs and then as downloadable archives. COTS is licensed by customers, who continue to install and operate it by themselves on their datacenters. Extensions and customizations, if any, are developed on IDEs like Microsoft Visual Basic Studio or COTS vendor’s low / no code platforms like Ramco Extension Development Kit. Customers pay COTS vendors a onetime license fee and recurring AMC charges every year. Examples of COTS vendors include Adobe, Oracle, and SAP.

Software As A Service (SAAS): The turn of the millennium heralded SAAS, where the vendor hosted the code on its cloud infrastructure and rented it to customers “as a service”. Apart from Salesforce, which pioneered the concept of SAAS, other leading SAAS vendors include NetSuite, Workday, et al. Customers pay SAAS vendors a recurring subscription fee. While subscription fees are denominated on a monthly basis in theory, many SAAS vendors insist on contracts for three years along with upfront payments for at least one year in actual practice. Depending on revenue recognition (RevRec) rules in their jurisdiction, vendors recognize revenues on a monthly basis or for the entire contract duration at one shot.

Custom Development is called BUILD, and COTS and SAAS are called BUY.

In the early-1980s, the pendulum started to swing from BUILD to BUY. SaaS Repatriation is a swing in the opposite direction, from BUY to BUILD.

There are two ways to look at SaaS Repatriation:

  1. It’s talking of book by venture capitalists who have invested in companies selling AI coding tools. My friends in Silicon Valley who know some angel investors personally assure me that that’s what this leading angel is doing.
  2. It has legs.

To speculate which is more likely to be the case, let’s look at the three advantages of BUY that were / are pitched by COTS vendors to drive the BUILD-to-BUY movement.

WYSIWYG: Business users are casual while describing their requirements. Developers build software on the basis of janky specs. Business users become serious only after the software is developed. At that stage, they test the software and dismiss it as being unfit for purpose. Massive amounts of time and money go down the drain. In contrast, COTS software can be seen before it’s bought. Business users can review the actual screens, workflows and reports upfront and can judge whether the software is fit-for-purpose before spending a dime.

Speed to Market: Custom development can start only after requirements are captured and will take months or years to finish thereafter. By then, business and technology will have changed, and the software will become obsolete. As against that, COTS software is ready to use (and to change in order to meet future requirements).

Best Practices: Custom developed software mimics the company’s existing business processes. By automating the AS-IS situation, it replicates the inefficiences of the business, and makes things worse by running suboptimal business processes faster on new generation hardware and software platforms. Whereas COTS software incorporates best practices from hundreds of companies worldwide and thereby provides a ready springboard for customers to vault themselves to the top of their industry by adopting the differentiators used by best-in-class companies to get where they have.

(SAAS pitched many advantages over COTS but those are irrelevant in the BUY to BUILD context of SaaS Repatriation.)

Let’s see how AI-driven BUILD, the linchpin of SaaS Repatriation, will fare against the aforementioned advantages.

WYSIWYG

All GenAI code assistants deliver code in response to a prompt in plain English. Many copilots even generate code in response to a screenshot of an app’s screen uploaded to them. GenAI Maxis would like to proffer that as proof that AI-based coding is as WYSIWYG as COTS or SAAS.

But I don’t buy that. When business users gave requirements in plain English for custom-developed software, the specifications got janky and software was found unfit for purpose. So I’m not so sure that the specifications of screens, workflows and other building blocks of a complex system can be expressed so easily in plain English. If natural language worked so well, structured requirement gathering methods like use case and storyboard would have never seen the light of the day and companies like Rational would have been dead on arrival.

According to me, this is an inhibitor, ergo -1.

Speed to Market

The average SAAS customer uses only 30-40% of the features of their SAAS product, so the scope of BUILD will be substantially lower than the functionality supported by the SAAS product they intend to replace. Furthermore, some people in this Twitter thread claim that they have used GenAI coding agents like Replit to build reasonably big apps in 45 minutes.

If this trend can be replicated at scale for real world applications, SaaS Repatriation may actually improve speed to market for custom developed software. That’s a +1.

Best Practices

At the risk of painting with a broad brushstroke, coders and operating level people don’t care about best practices in packaged software and might not miss their absence in the BUILD option. However, the C Suite of most companies is totally sold on this advantage of COTS / SAAS and will balk at losing it by moving to inhouse development.

Depending on who calls the shots in a company, this will prove irrelevant in some companies and an inhibitor in others. That’s a 0.

If we total up the scores of the AI BUILD option against these three factors, we reach a tally of 0 (-1 + 1 + 0).

So the outlook of SaaS Repatriation is inconclusive.

Does it mean it will have no impact?

No. I expect that SaaS Repatriation  will have three areas of impact in the short term. I’ll cover them in a follow-on post. Watch this space!