Three hundred plans
Why cheaper software means more of it, not less
I have a friend who, given any two possible outcomes, always picks the darker one. He is the kind of person who reads a headline about record wheat harvests and immediately asks about soil depletion. When the topic turns to AI, he has two takes:
Take one: every company will vibe-code its own Salesforce, making SaaS extinct.
Take two: companies will use AI to fire 90% of the workforce and keep the same output.
A lot has been written about the death of SaaS. I covered it in detail a few weeks ago, but the short version is: companies will not spend time and tokens to rebuild Workday in house, and they will keep focusing on their core product.
The productivity gain angle is more interesting. I ran some numbers in this other post to see if AI capex is in the ballpark of what companies spend on SWEs, and also in this case the doom narrative doesn’t survive scrutiny.
The doomist approach assumes implicitly a fixed pie, where the same output gets produced by fewer people. This assumption has been wrong every single time it has been made about a productivity technology. Spreadsheets did not eliminate accountants, they created the job category of financial analyst. The web hurt retail stores with e-commerce, but didn’t wipe them out, and commerce employment and volume kept growing alongside it.
When you make something dramatically cheaper to produce, you get more of it, not less. It’s called the Jevons paradox. If building software becomes 10x cheaper, the world does not end up with the same amount of software at a tenth of the cost. It ends up with vastly more software. There is a ceiling, of course, because organizations can only absorb so many tools before coordination costs eat the gains. But we are nowhere near that ceiling. Mo Bitar made this point well: we are heading toward an explosion of software, not a contraction.
Think about what currently does not get built. Internal tools that would save a team four hours a week but never survive prioritization. Integrations between systems that technically have APIs but nobody has the bandwidth to connect. Dashboards for departments that are too small to justify the engineering time. Analytics features that would be useful for 200 customers but not for 2,000. All of that might become cheaper to build, and therefore possible.
The doom narrative ignores that SaaS vendors are not sitting idle while their customers discover AI. They are using the same tools. Imagine if a feature request that took a sprint now takes a day. Or a connector that required a dedicated team can be scaffolded in an afternoon and polished in a week.
The bottleneck for SaaS companies has always been prioritization and resources, not ideas or capabilities. Any mature SaaS product has a backlog of hundreds of feature requests, a graveyard of GitHub issues marked “wontfix” because the engineering cost does not justify the audience size. When that cost drops by an order of magnitude, the calculus changes completely.
So what if instead of SaaS dying, we will have SaaS hyper-personalization?
Today, the typical SaaS pricing page has three tiers: Free, Pro, Enterprise. Every customer in each tier gets the same product, because maintaining multiple versions of the same software is expensive. If AI drops the cost of building and maintaining product variants, that constraint loosens.
Take a vertical SaaS company selling practice-management software to dental clinics. Today they ship one product. With AI-assisted development, they could ship a variant for orthodontists that handles treatment-plan workflows differently, another for pediatric practices with consent-form logic built in, another for multi-location groups that need cross-office reporting. Each variant shares a common core, with AI-generated adaptation layers on top. The vendor still amortizes infrastructure, security, and compliance across all customers, but the product surface area expands to fit each segment instead of forcing everyone into the same mold.
The obvious objection is that maintaining hundreds of variants sounds like a nightmare. More variants means more edge cases, more regression testing, more security patches across diverging codebases. That’s why SWEs have a bright future, there will be a lot of software to maintain !!!. We could move from a world of three plans to a world of three hundred variants. The feature request graveyard starts getting cleared because the economics of saying “yes” have changed.
This is the opposite of SaaSpocalypse, it’s a Cambrian explosion of SaaS. My pessimistic friend will not be convinced by any of this. But I think the more likely future is one where your CRM knows your sales motion, your project tracker fits your sprint cadence, and no two companies run quite the same stack. Weirder and more personal than either of his doom scenarios.
Do you like this post? Of course you do. Share it on Twitter/X, LinkedIn and HackerNews