Ancient History

The key innovation of Software as a Service (SaaS) was a new model for software distribution. A brief-ish history that you’re welcome to skip…

• IBM Mainframes originally used paper punch cards to load software. Do not fold, spindle, or mutilate. Later, reel-to-reel magnetic tape replaced paper. Business users rarely interacted directly, but instead were delivered printed output with perforated pages.
• Mid-range systems such as AS/400 and HP-3000 did away with punch cards, but magnetic tape still ruled. Software updates arrived in padded envelopes, and only operators saw them. Clerical staff might have dumb terminals, but little more. Managers and above still worked with paper.
• As PCs became commonplace, the media used to distribute software changed rapidly from cassette tape, to 8” floppies, then 5.25”, and finally 3.5”. Managers started using PCs, but still relied heavily on paper for reporting and decision-making.
• As client-server took over, much of the business software was installed on the server, and users ran it via LAN. Updates arrived via CD, and for single-machine use mysteriously loaded in the pop-out cup holder. Paperless was a distant dream for all but a few early adopters. Besides, faxing your screen is silly.

SaaS Revolution

SaaS changed the game. Accessible from anywhere, no infrastructure required, only a working connection. Updates daily, hourly, whatever was required. Move fast and break things. Printers and fax machines were for luddites.

The pioneer was Salesforce, and they’re still the largest pure SaaS company. By the 2010s, “SaaS” was part of standard business vocabulary. Startups in the space were exploding, and that’s continued as more and more business processes move online.

AI Metamorphosis AKA SaaSpocalypse

Agentic AI is seen as a threat to SaaS hegemony, and it is — and it isn’t. Come again?

SaaS companies thrive by delivering a low-friction experience backed by solid domain knowledge. As more and more code is written by AI models, the effects will vary by customer tier.

Enterprise

Expect serious disruption. Companies in this space have the budget to create bespoke software at a rate never before seen. Enterprise SaaS isn’t dead, but the domain knowledge of the provider has to outweigh the implementation friction of their solution.

There is a big difference between bespoke systems streamlined for your specific processes versus SaaS in a utility role. Writing your own sales order process might be justified, but even the largest companies won’t be eager to reinvent email.

Many will choose to create swarms of AI agents that bridge the gap between “legacy” systems and modern collaboration platforms such as Slack or Microsoft Teams.

Note: Offering Model Context Protocol (MCP) integration will be table stakes for SaaS providers. I want to stay out of the weeds, but MCP is essentially an abstraction layer that allows AI agents to interact directly with an external system.

SMB

The disruption will be less. While companies may find it easy to create custom solutions, infrastructure and maintenance/upkeep continue to be real costs. Vibe coding your way to a tool that works wonderfully for your current process is easy. Having the discipline to apply security patches as the libraries you’re using are discovered to have vulnerabilities is not. Zombie projects are a real risk. And it remains to be seen how well homegrown solutions scale as the company grows. More likely is the use of MCPs to create custom wrappers around existing SaaS solutions.

Individual

Customers whose needs are slightly different than the mainstream will have the option to roll their own. They’ve always had that option, but it’s never been as easy as it is now. Sophisticated users are creating custom interfaces for any number of external services. And some have embraced an open source framework called OpenClaw to create their own personal assistant! I named mine Pepper…

Implications for SaaS

SaaS will survive. Existing software holds significant value for clients who don’t already have their own dev teams and/or domain knowledge. And it simply isn’t worth the lift to replicate a tool that’s not specific to your business model. SaaS that isn’t industry-specific should continue relatively unscathed if it’s low friction.

The most visible effect will be competition. Competitors will rise with relatively little capital, creating a long tail of startups who see themselves as the next Slack. Some of them will be so niche that they serve only a handful of customers. Most of them won’t cross the chasm.

The more interesting effect is extension. Clients who can afford to hire or outsource to even one engineer will find ways to build a private ecosystem around their SaaS tools. There will be an explosion of bespoke software and workflows that we’ll implement to get work done in more efficient ways. Or at least ways that seemed like a good idea at the time. Eventually the best ideas will be incorporated into the mainstream SaaS offerings, raising the baseline of what is possible and expected.

SaaS isn’t going on the cart. But what emerges from the cocoon won’t look much like what went in.

Join the Conversation on LinkedIn

Low-code and no-code tools are advancing at an astounding pace, but the first challenge of proof-of-concept (PoC) work remains knowing what to build.

What are you trying to prove?

Let’s start with a physical example.

You’re designing a grown-up fidget toy for mass production, so you make a small batch of prototypes—maybe only one. You show them to widening groups of family, friends, and strangers to learn from their reactions. You refine the concept and make fresh batches. Only once you’re confident in the design do you order a large production run. In fact, you might even launch a crowdfunding campaign to gauge interest before committing.

Now, let’s move to the digital realm.

You plan to disrupt a service industry still stuck in the dark ages of manual processes—much like Uber did to taxicabs. To do this, you’ll need to accept a request from a consumer, interact with four or five APIs, coordinate a network of gig workers, and orchestrate a seamless experience.

Since your vision is clear, you work out the key features, user flows, and automations that will make your service stand out. You capture it all in a document an LLM can understand. And then you build it. Oh my God, do you build it—refining and fighting with the LLM to get every last detail right. Days or weeks later, possibly with help from actual software engineers, you have a working prototype. The PoC from your vision is now a reality. You test it in the wild, then announce your arrival to the world.

This is the moment of truth.

You find out what you missed. And depending on the miss, you might have to start over.

Wait, what?

What assumption are you testing?

Something critical gets lost in the digital example: lean startup philosophy tells us to test our assumptions. Chief among them is whether customers are even willing to leave the incumbents. If you can’t convince them to engage, it doesn’t matter how polished your technology is. This is the digital equivalent of strangers refusing to touch your fidget toy.

Do NOT order a large production run!

In many cases, the simplest path is the best. Maybe as little as a form submission. If it validates your hypothesis, it’s doing its job. The orchestration can remain manual until you have validated learning around the problem space and consumer needs.

Do things that don’t scale. — Paul Graham

The point of a PoC is speed and learning, not perfection. Once you know the solution is viable, then you can invest in building it for real.

Join the Conversation on LinkedIn

Perception

One of the teams I worked with was pouring a great deal of effort into moving slow background processing from Ruby/Sidekiq to JavaScript/Lambda, and Ruby was considered “legacy” by much of the team. The prevailing perception was that JavaScript was inherently faster than Ruby, Lambda was far superior to Sidekiq, and anything ported between them would automatically be faster.

Soon after joining the team, I made a database change that caused a Ruby unit test to fail. It was an easy fix, and I included it in the changes I submitted for code review. One of the reviewers commented that the code I fixed was obsolete and should be removed. Out of curiosity, I took another look at the Ruby code—and the JavaScript that replaced it.

I didn’t like what I found. Here’s the Ruby process in a nutshell:

• Query ~100,000 rows from table A in chunks of 1,000 using LIMIT and OFFSET
• Break each chunk of 1,000 into smaller chunks of 10 for insertion into table B

This didn’t happen in nested loops. Instead:

• The top-level routine read each chunk of 1,000 and queued it for level 2 using Sidekiq
• The level 2 routine broke it into chunks of 10 and queued those for level 3 using Sidekiq
• The level 3 (and final) routine inserted each chunk of 10 into table B using a single INSERT statement

The data was modified during the process, so it couldn’t be a direct table-to-table copy. But if you follow the convoluted process above and do the math, you’ll see:

• Table A is queried 100 times
• Table B is written to 10,000 times
• Sidekiq handles 10,101 invocations across 3 routines

As I was going to St Ives,
I met a man with seven wives,
Each wife had seven sacks,
Each sack had seven cats,
Each cat had seven kits:
Kits, cats, sacks, and wives,
How many were there going to St Ives?

The new JavaScript code did much the same thing, except:

• It substituted Lambda for Sidekiq
• It introduced a data error because the developer misunderstood a bit of Ruby logic

Reality

Ruby vs. JavaScript is out of scope for this post, and Lambda definitely had an edge here simply due to its higher concurrency.

HOWEVER, the real performance limit was the database access pattern.

Here’s a better approach:

• Create a temporary table matching table B
• Copy the 100,000 rows from table A to the temp table using INSERT ... SELECT
• Modify the data using UPDATE
• Insert the rows into table B using another INSERT ... SELECT
• Drop the temporary table

The entire process only needed 5–7 queries in a single invocation. And even though the runtime of the single job was significant, it still ran ~3× faster than the JavaScript/Lambda implementation—largely because the data never left the database. As a bonus, the entire task was now atomic.

Oh, and we moved the job back to legacy Ruby/Sidekiq—because consolidating 10,101 invocations into one caused timeouts in Lambda.

A few years ago, my team was maintaining a critical ETL process. An exec got excited about Astronomer and asked me to evaluate it. After a couple of hours with a trial account, I concluded our needs were too complex, explained my reasoning, and moved on. Case closed—or so I thought.

Some time after I’d left, the idea resurfaced—same exec, same goal. This time, the team spent six months trying to make it work. They failed. My successor was shocked to discover I’d previously told the exec it wouldn’t succeed. In a moment of ironic vindication, I later saw the then-CEO of Astronomer (not Andy Byron) publicly cite our failed project as an example of SaaS trying to do too much.

This isn’t a knock against Astronomer—the current version might easily handle the job. The real issue wasn’t technical; it was human. And no LLM can paper over that.

So here’s what I’m still pondering:

• How can leaders differentiate negativity from foresight when someone resists a “new” idea?
• How could I have communicated differently—since, clearly, we weren’t on the same page?

P.S.—I’ve been doing this long enough that some new ideas feel like I’m Merlin remembering the future.

Join the Conversation on LinkedIn