Growth
May 21

AI as the Next Infrastructure Wave (Part 1 of 3)

We’ve developed a deep understanding of the infrastructure that shapes the way we interact with tech. In this three-part series, we dig into the six key trends that we believe have defined the evolution of software.

Over the last 20 years BuildGroup’s team has developed a deep understanding of the infrastructure that shapes the way we interact with tech today. In this series of blog posts, we dig into the six key trends that we believe have defined the evolution of software and how AI fits within this context. This is part one of three. 

If you’d like to read an AI-generated summary of this post, scroll all the way to the bottom (thanks, Claude!). 

It’s probably obvious to anyone reading this that the landscape of technology has undergone profound transformation, driven by a series of pivotal inflections over the last 25 years. The BuildGroup team experienced these transitions as we led companies such as Rackspace and projects such as OpenStack that were critical catalysts for these changes. These inflection points drove profound shifts in how software is built, how it is distributed, or how it is consumed. And those changes were dramatic.

In the B2B software world, names such as Salesforce, VMWare, Rackspace, and Workday are associated with many of the big changes that we have seen since 2000.  Each of these companies was critically important in driving massive changes in our industry. As a result, investors are often looking for the company defining the next wave of technology. Today, that means looking for companies such as Anthropic or OpenAI who are architecting the LLMs and AI upon which we increasingly depend. 

But, what is missed today – as was in the past – is the “infrastructure waves” that these companies either help create, or rely upon, or both, and their impact on all software companies.  Each of these infrastructure waves had the potential to lift all boats. And for those companies who were best prepared to ride the wave, it lifted them even higher. 

Some of these waves are very closely related to each other and therefore hard to distinguish, such as SaaS and the rise of cloud platforms. Some have very clear start dates, such as the birth of mobile with the launch of the iPhone, while others less so, such as open source. But each of their impacts was very distinct and more importantly, each wave has built upon the previous and amplified it. We at BuildGroup have had a front row seat to all of these changes. Our belief is that the latest wave in AI will have the greatest amplification effect we have seen to date. In order to explain this effect, we dive into each of the six major waves and how together, they have driven technology to where it is today. 

 

Wave 1:  Software-as-a-Service

Prior to SaaS, there was something called client-server. Applications were consumed within a single house or within a single corporate network. If you were a gamer, you bought a CD of Doom (in a store of course, not online!), you loaded it into your CD drive to install it, and then you played. If you were a geek like me, you used your phone modem to dial a friend and play Doom against each other while Pearl Jam played in the background. If you were a corporation, you would order a copy of Windows 95 to install separately on every desktop in your environment.  Or you got a gold-master DVD of Windows Server NT to install on your server for use on your corporate network. But technology at that time was built, distributed and consumed on a 1-to-1 or single company basis.

During this time, customer relationship management (“CRM”) software was becoming popular for use in marketing, sales and customer service. There were tools like ACT! and Siebel that were popular with small and medium companies, and large enterprises, respectively.  But because they ran on client-server architectures, these were one-to-one relationships between user and software. The data you have in your desktop copy of ACT! would not mirror what your colleague had, or would require some sort of manual sync. And the worst part was you couldn’t actively collaborate with your colleagues with the application because each instance was unique and not connected. If you wanted someone to review an interaction you had with a customer, you might be able to email them the data, or worse, print it out and put it on their (literal) desktop inbox.

Software companies had no real-time visibility into how you were using their software. To explore how their products were being used and where to improve them, software companies employed surveys, feedback groups, and other offline methods. For corporate software, there might be “phone home” capabilities for servers or other software on the network, but the data it collected was usually basic and insufficient on its own.

The sale of these products was usually just that – an upfront sale. Consumers paid for their software when they purchased, and not again until they purchased another release.  Enterprises also paid upfront, and often had to pay up to 20% of the initial cost per year for “maintenance” which included support and upgrades. This made software much more of a capital expense versus an operating expense. Each decision had to be carefully considered, because the upfront costs could often be very high and the benefits of deployment in the far distance. When software companies wanted to do major feature upgrades, they would hold them for new releases, which often meant years between upgrades. And because upgrades required enterprises to deploy new code in their software and hardware environments, they were treated as major projects that often required extensive preparation and testing.  I lived this model while working in sales for Bowstreet where we were pricing software ”by the core” for a lot of money upfront – long before the customer ever saw any value – and then working with them for quarters to get it deployed.

Into this environment came the software-as-a-service model, or SaaS, and its success was epitomized by Salesforce. 

This wave impacted all three major categories of infrastructure – building/deploying/maintaining, distributing, and consuming – and became the fundamental basis upon which each ensuing infrastructure wave was built.

This is the only wave where being an incumbent did not offer advantages, and in fact, was quite a disadvantage. Legacy client-server software companies had invested millions of dollars in building stand-alone software architectures that could not easily be converted into SaaS architectures, or what are now called “multitenant” or “cloud architectures”. If you want to know how difficult this transition is, just consider how many large enterprises still run legacy environments due to the difficulty of migrating to cloud infrastructures.

The business models of legacy companies were completely oriented around the legacy sales and distribution model, creating tremendous friction for any transition. Startups such as Salesforce had none of this legacy baggage and were able to move quickly to seize the moment. Many of the larger incumbents such as Microsoft and Oracle were able to make the transition over a much longer period of time (typically by acquiring SaaS-native businesses), but many incumbents did not. Just consider how few companies use Siebel and ACT! Today.

Once Salesforce became the reference for SaaS, other startups were quick to follow. And the market was quick to jump on SaaS as a much better model for buying and using software. This led to the second major infrastructure wave – cloud platforms – just a few years later.

Wave 2:  Cloud Platforms

From an operating perspective, SaaS was a huge change for software companies. For years they had been building software for their customers to run and manage in their own environments.  Customers would handle all aspects of deploying the software, and maintaining and upgrading it. Sometimes software companies would offer services to help their customers, or they would have networks of service partners to do the same, but in the end it was the customers’ responsibility. 

In the world of SaaS, software companies were now responsible for the full lifecycle of operating a software environment for their customers. And to make matters even more challenging, companies were maintaining a single platform for all of their customers at the same time.

Addressing an issue could now take down all customers at the same time! New methods of deployment and change management had to quickly be adopted. From a financial perspective, software companies now had to budget for data centers comprising servers, storage and networks. All of a sudden, building new software not only included the cost of writing code, but also the capex required to deploy the infrastructure on which it needed to run. Effectively, the operating and financial challenges faced by customers in the client-server world had been shifted to software companies in the SaaS world.

Companies such as Rackspace emerged to address this challenge. Rather than build and run their environments in their own data centers, SaaS companies could entrust Rackspace to provide the infrastructure “as a service”, including the staff required to support them. The infrastructure required to run SaaS software environments was maintained by Rackspace rather than the SaaS companies. Those companies were now free to focus on developing what was really critical to their success – the application layer – and leave the underlying infrastructure layer to experts who could operate at scale.

Now starting a SaaS company no longer involved all the upfront infrastructure costs, and instead infrastructure spending could scale as the business scaled. The people required to maintain the infrastructure no longer had to be employees at the SaaS company, but rather would work at their provider, such as Rackspace. This led to tremendous cost advantages for the companies who moved to this new “hosted” model. However, while this wave was important, it was more of a transitional wave between client-server and cloud platforms for one primary reason – the actual hardware and network layer was still “dedicated” to each customer or environment versus shared, or multitenant.

The first cloud platform emerged with the launch of Amazon Web Services in 2006. Amazon was a native SaaS company which had been running its own infrastructure in its own data centers for years. Server “virtualization”, driven by companies such as VMware and open source projects such as KVM and Xen, became mainstream. The concept of a “server” was no longer tied to a single, physical server. One physical server could have many virtual servers. The concept of a “server” therefore switched from a physical one, managed in the physical world, to a piece of software managed via software. 

Similar virtualization capabilities swept the storage and networking worlds, empowering companies such as Amazon to construct virtualized infrastructure for deploying and managing its software. Amazon became an expert at how to build, deploy and maintain a cloud platform, and decided in 2006 to productize these capabilities – launching the cloud platform wave.  Rackspace and many other large providers such as Microsoft were soon to follow.

Like SaaS before it, this model had major benefits to those SaaS companies who switched from the “hosted” model to the cloud platform model. The first was simply cost. A virtual server cost far less than a full physical server. The second was uptime and redundancy. If a physical server failed, it was easy to move to virtual servers elsewhere. The last was scalability. Growth prior to cloud platforms could be slowed by the need to deploy physical gear as customers and traffic expanded. Now it was easy to quickly spin up new infrastructure as growth demanded it — or to spin down with seasonal or recession-driven declines in usage. In the old world, any unused equipment would just sit unused and depreciate until usage picked up again.

Most of the benefits of this infrastructure wave were isolated to how software was built, deployed and maintained. But those impacts were dramatic. Infrastructure had become software. You managed infrastructure with software. And customers interacted with it via APIs. SaaS companies started writing code into their programs to manage the infrastructure – expanding or contracting it, etc. – and stopped hiring the personnel required when infrastructure was physical.

At Rackspace, we saw this transition as our SaaS customers quickly indicated a preference for the Amazon Web Services model. Without a cloud platform, we were at a significant disadvantage. This led us to launch the Rackspace Cloud in 2008. But because infrastructure had moved to software, and was no longer about how you managed physical infrastructure, we were at a severe disadvantage. The writing was already on the wall for us, but that is a topic for another article.

In general, most SaaS companies successfully managed this transition, as they had already set up a “cloud” architecture and had developed the business model to match it. This was an example of almost all boats being lifted equally by an infrastructure wave. It simply left those legacy client-server companies who had not transitioned to SaaS even further behind. It was at this point that companies like Microsoft really saw the danger in not converting its offerings full to SaaS, as well as the huge opportunity if they did. Microsoft and Google in particular understood the risk and opportunity dynamic, ultimately getting into the cloud platform market to compete against Amazon.

Here’s the Claude AI summary of parts 1-3 of this series:

The post discusses BuildGroup's investment thesis, which is centered around understanding the major infrastructure waves that have shaped the evolution of software and SaaS companies over the past 25 years. It identifies six major waves:

  1. Software-as-a-Service (SaaS)
  2. Cloud Platforms
  3. Mobile
  4. Open Source
  5. Data Science
  6. Artificial Intelligence (AI)

Each wave had a profound impact on how software is built, deployed, distributed, and consumed. The document provides details on how companies that were able to ride these waves early on gained significant advantages.The author believes the latest AI wave will have the greatest amplification effect. Data-enabled SaaS companies that have already amassed large proprietary datasets and domain expertise are best positioned to successfully integrate AI and become "AI-enabled SaaS" companies.

The document uses examples like Fiix, Casetext, and Anthropic to illustrate how companies transitioned through these waves. It argues that AI will dramatically improve software usability, abstracting users away from managing workflows to simply querying an "AI co-pilot." Overall, the thesis is that investing in early-growth, data-enabled SaaS companies ripe for AI integration represents an exciting opportunity to back the next transformative wave in software.

Continue to part 2.

Enjoying this series? Subscribe to our newsletter for more Building Blocks from BuildGroup. 

The information in this blog post is provided in good faith without any warranty. It does not constitute investment advice, recommendation, or an offer of any services or products of BuildGroup Management and it is not intended to provide a sufficient basis on which to make an investment decision. This document is provided for educational purposes only. Discussions of current or former BuildGroup portfolio companies are intended for educational and discussion purposes only. Any portfolio company so discussed has been selected based on objective, non-performance based criteria.

This content does not constitute or form part of an offer of any investment advisory services of BuildGroup Management, LLC, nor does it constitute or form part of an offer to issue or sell, or of a solicitation of an offer to subscribe or buy, any securities or other financial instruments, nor does it constitute a financial promotion, investment advice or an inducement or incitement to participate in any product, offering or investment.