One benefit of being in this industry as long as I have is that you can step back and see the arc of the curve. The arc explains why what’s happening right now is not just another technology transition. It’s the end of a 30-year compromise.
Here’s how we got here.
Rusty Beemers on 128
I arrived in the Boston area and the software industry in the early ‘90s. For those not old enough to remember, this was right at the end of the microcomputer era. I can still recall my first boss telling me about all the rusted-out BMWs cruising Route 128, the result of ongoing layoffs from Wang, Prime and DEC. Ironically, we sold software to those companies’ customers.
The customers got the memo, but took some time to act on it, as they still had their VAXes, their PDP-11s, and their IBM mainframes plugged in and running mission-critical work. Nobody was unplugging what worked, not quickly at least. That’s the first lesson, and it repeats: the vendor economics die years before the installed base does.
Where it got interesting—and fun for me—was when that started to change.
From Big Iron to Enterprise Software
My next role landed me in the middle of the rise of “client-server.” Some have only heard that term in a legacy context, but the term itself doesn’t matter much. What it enabled is what’s important: a new platform for computing, and for software running on a network, rather than a single machine.
What client-server ultimately enabled was the thing we ended up calling Enterprise Software. SAP. Oracle. PeopleSoft. Siebel Systems. A long list of companies, some still with us, others long forgotten.
Alongside the vendors came the consultants. I particularly remember Michael Hammer, whose Reengineering the Corporation provided the intellectual scaffolding for the whole era. “A Manifesto for Business Revolution” no less!
The Reengineering pitch, in a nutshell: we have this new computing platform, and it can help enterprises (of course) re-engineer themselves. Which really meant changing how they operate by automating their processes.
Adapt the Business to the Software
Here’s what that looked like in practice. SAP — the leading example in the early days — shipped standard modules. Finance. HR. Warehouse management. Supply chain. Support tickets. You bought it, ran it on top of your client-server network, and it standardized those processes for you.
Which was genuinely appealing, because how do big companies get big? They scale. How do they scale? They standardize. Enterprise software was a standardization machine sold to organizations whose entire growth model depended on standardizing, and who never before had the ability to standardize on an enterprise-wide basis.
But notice the order of operations: it was not about adapting the software to your business. It was about adapting your business to the software.
Yes, there was flexibility at the margins. SAP famously had ABAP, which let you customize your processes to a degree. But you were building on top of what the software gave you. The application’s model of how a company works was the starting condition, and your business was the variable.
Importantly, this was a massive improvement over what came before. Wildly popular, and in some cases wildly successful. In other infamous cases, catastrophic. But successful or not, the enterprise software decision was a standardization revolution, and just about every large customer signed it.
The Departmental Revolt
In the late ‘90s, that starts cracking with the rise of business use of Netscape and the internet, which suddenly promised the opportunity for users to run anything as long as it ran in a browser. We weren’t calling it “SaaS” yet — the precursor was Application Service Providers (or ASPs). Web-hosted software, delivered via the ubiquitous web browser.
What ASPs enabled were compartmentalized, departmental solutions. There was real demand for that, because inside every large organization you would have senior leadership looking at enterprise-wide processes — but you also have the xVPs of Sales, Marketing, Supply Chain, HR, etc…. And to those people, a monolithic ERP system was too much. Too heavy, too slow, too far from their actual problem. Not to mention far too expensive for the CFO, especially considering the armies of high-priced consultants who needed to fly in every week to install it, customize it, and support it.
There was an accessibility problem too. Early enterprise software and mobility didn’t mix. The iPhone didn’t exist yet, since phones made phone calls but they didn’t run apps, at least not apps robust enough to be useful. Users had laptops, but syncing from a remote environment was a miserable experience of moving the bed away from the wall in the hotel to sync over a slow dial-up modem before you could get any real work done.
Eventually ASP evolved into the SaaS we know today: innovators like Salesforce disrupting Siebel and Workday doing the same to PeopleSoft demonstrated that enterprise capabilities could really be delivered in a browser, and widespread broadband made the SaaS promise real.
SaaS offered a more compartmentalized approach to process management. Rather than a company-wide re-engineering exercise — which the monolithic ERP systems required — you could bring on a departmental solution to run sales, or marketing, or the warehouse. Less comprehensive. Far more flexible. Built for the xVP, not the C-suite.
The downside was that it steered us away from true enterprise-wide process integration. APIs showed up to patch that, and mostly did.
The Covid Adaptation and the ZIRP Blowout
All of this went on for quite some time - bandwidth and browsers kept improving on the front end, and APIs and web services on the back end. Integration got easier - if not perfect - and the world settled into a rhythm. Investors loved it and predictable metrics like ARR and NDR became metronomes of the SaaS economy, and those rusty Beemers were much harder to find.
Then came the pandemic, and everything kicked into hyperdrive, when two things happened at once.
First, every enterprise suddenly had to work remotely, and the existing SaaS stack didn’t always fit how work now suddenly had to happen. New solutions emerged to fill the gap - Zoom being the most obvious example: built for the suddenly remote environment everyone was abruptly living in.
Second, governments unleashed a ton of free money, as interest rates went to zero and loan programs like PPP recharged corporate balance sheets. The SaaS market, in turn, went a little nuts. From late 2020 into early 2022 there was an absolute blowout of new SaaS providers funded on cheap capital. What we actually got was an over-proliferation of me-too next-gen products. And the old stuff was all still running.
Which brings us to present day.
Where We Are and Where We’re Going
Today’s market has a vast over-proliferation of SaaS, with the market working off an oversupply of me-too point solutions, and CFOs and CIOs partnering to consolidate their tech stacks. I did a survey about this with CIO.com in 2023 and the customer feedback couldn’t have been more clear.
There’s a hierarchy to SaaS. At the foundation, the core systems of record, from the SAPs and Salesforces, still run not just departments but entire business units. Attached to those SORs sits a sprawl of single-function point solutions, what I’ve always called the solutions in the App Store.
Every one of those SaaS solutions, from the largest ERP down to the smallest point tool, is sold on the same fundamental bargain that was struck in the early ‘90s. The vendor built one model of the process. You adapt your business to it. You pay per seat for the privilege, though there’s some experimentation around the edges with usage-based and value-based pricing.
Until, suddenly, the advent of ChatGPT and the generative AI wave. What started as chat interfaces quickly revealed where the real leverage was: generating code. Almost overnight, the core economic reality that dictated thirty years of IT strategy began to collapse. Led by Anthropic’s Claude Code, Cursor, Lovable, Replit and others, suddenly enterprise attention is turning from an era of buying standard software to one of generating bespoke systems.
The Reversal
For thirty-plus years, software was expensive to build and cheap to copy.
That single economic constraint dictated the entire structure of the enterprise software market. It’s why vendors amortized one rigid, opinionated process model across thousands of customers. It’s why enterprise buyers absorbed the friction between that generic model and how their business actually ran. The mismatch was a massive, recurring operational tax—but because building from scratch was impossible, everyone paid it and called it “best practices.”
Now, the cost of generating software is rapidly collapsing to zero. The entire bargain inverts.
Instead of twisting the business to fit the software, you can now build the software to fit the business.
This isn’t an incremental efficiency gain for the SaaS playbook; it’s the elimination of the premise SaaS was built on. Incumbents cannot defend against this by dropping seat prices, because customers were never buying the seat. They were buying someone else’s process—out of necessity.
When you can direct autonomous agents to spin up, integrate, and continuously modify systems tailored precisely to your operating model, the concept of a multi-tenant application suite starts looking as dated as a client-server rack in an on-prem data center.
The vendor economics always die long before the installed base does. The legacy SaaS stack won’t vanish overnight, but the mandate has already shifted: the thirty-year compromise is over, and the leverage has returned to the enterprise.
Transitions this fundamental only come around every few decades. The new playbook is barely being written, and it is going to be thrilling to watch.
Great history lesson and insight Chris. Any comments on what happens to specific industries like for-profit education? All our schools buy lots of software for curriculum, testing, tutoring etc.