SaaS Is Dead? Alex Becker on AI-Era Software | Guide

SaaS Is Dead? How Alex Becker Sees Software Evolving in the AI Era

TL;DR

• SaaS is a subscription software model whose real moat was always customer dependency, not code complexity.
• All-in-one SaaS platforms are weakening because most customers use only 10–20% of bloated feature sets.
• Composable SaaS is a modular approach where companies assemble only the features they actually need.
• Infrastructure-layer API providers for payments, email, and data will gain power as front-ends get cheaper.
• The winning business model is framework design plus custom assembly and ongoing maintenance as a subscription.

Introduction: Is “SaaS Is Dead” Just Clickbait?

“SaaS is dead.”

When a random commentator says this, it sounds like provocation.
When Alex Becker says it, people building software businesses should pause and listen.

Becker is a serial founder who has launched multiple SaaS companies and reportedly generates sales in the hundreds of millions per day. That same person is now arguing that the current SaaS model is structurally broken in the AI era — and that many companies won’t make it unless they fundamentally change.

He’s not predicting that SaaS as a category disappears. He draws a clear line: if SaaS stays in its existing all-in-one, product-selling form, a lot of players will die. If it evolves into structure design and custom assembly, the opportunity may be bigger than ever.

What follows breaks down his core argument so founders, developers, and buyers can understand:

• Why the SaaS model is under real pressure right now.
• How AI is changing structure, not just code.
• What “composable SaaS” and “infrastructure layers” actually mean in practice.
• Where the software opportunity may lie over the next year or two.

In my own work with SaaS founders, I’ve started seeing this pattern too: customers are less impressed by feature lists and more interested in “a system that fits how we already work.” Becker is putting sharp language around a shift that’s already happening.

Why Coding Is Not the Real Barrier in SaaS

Coding as a barrier in SaaS is a common misconception that AI tools have amplified but not fundamentally changed. The popular narrative runs: “AI now writes code, so anyone can build SaaS, therefore existing SaaS is finished.” It sounds logical. But Becker argues that’s never where the real moat was.

Historically, when a genuinely profitable SaaS idea surfaced, capital and teams followed fast. If a service crossed a meaningful revenue threshold, competitors would copy the concept, hire engineers, and ship similar features within months. The ability to write code was never the real bottleneck for anyone playing seriously.

“The fundamental barrier of SaaS was never coding. The truly hard part was making customers continuously and properly use the software.”

That reframes the issue:

• Coding was always outsourceable — through hiring, agencies, or now AI.
• Customer dependency — getting users to actually rely on the product and weave it into their workflows — was the real challenge all along.
• AI code generation doesn’t resolve this. It just makes the background condition of “many competitors can build similar tools” even more extreme.

Testing AI-assisted app builders like Bubble with AI plugins, or using GitHub Copilot in real client projects, makes one thing clear: building a basic app has become dramatically easier. What hasn’t become easier is driving daily active use, embedding the tool into team habits, or preventing churn once the novelty wears off.

So AI didn’t “kill” SaaS by breaking the coding gate. It exposed that coding was never the real gate in the first place.

For background on SaaS economics and churn, Becker’s argument holds up well against classic SaaS metrics thinking from sources like For Entrepreneurs on SaaS Metrics.

Customer Dependency as the Real Moat: The Hyros Example

Customer dependency is the degree to which a client’s operations and outcomes rely on a particular software product. In Becker’s analysis, this is the core life force of any SaaS business — and his ad tracking tool, Hyros, shows exactly why.

Hyros had a clear feature: ad tracking. Clear value: measure which ads make money. But early on, customers didn’t settle in easily. They struggled to understand it, couldn’t see concrete results, and never integrated it tightly into daily workflows.

To fix this, Becker spent nearly six months in close contact with early customers:

• Watching where they got stuck.
• Simplifying or redesigning confusing parts.
• Adjusting flows until results became obvious and actionable.

He wasn’t just adding features. He was binding customers into a system where their data accumulated inside Hyros, their workflows started depending on metrics from Hyros, and their teams onboarded into it as “how we measure ads here.”

“In the end, SaaS is not a game of building well. It is a game of making customers dependent.”

That’s where the real switching cost lives:

• Historical data is stored in one tool.
• Processes and automations are built around that tool.
• Multiple departments coordinate inside it.

Even if a rival offers similar features, or AI promises a faster rebuild, the cost of moving becomes too high. This dynamic is consistent with lock-in patterns documented in broader software switching research.

Working with companies migrating from one CRM to another, the blocker is almost never “Will this new CRM have that feature?” It’s always the same three questions:

• “What happens to our existing data?”
• “How long will our sales team be in chaos?”
• “Who redesigns our pipelines, automations, and reporting?”

Becker’s conclusion: AI-generated code doesn’t touch this moat. But how SaaS is structured — especially all-in-one platforms — does.

The All-in-One SaaS Platform Paradox

All-in-one SaaS platforms are large, multi-feature systems that attempt to serve many industries and use cases under one roof. Becker argues that this structure itself is now the main source of fragility in the SaaS model — not AI coding tools.

To serve “everyone,” these platforms were forced to continuously add features for every edge case and vertical, pile on configuration options for different workflows, and support industries with wildly different needs. Over time, that produces platforms that are massive in scope, complex to set up, and expensive in licensing, training, and maintenance.

Real-world usage is lopsided. Most companies end up using only 10–20% of the total feature set while still paying for — and learning — 100% of the system.

“Companies often only use 10–20% of a platform’s features, yet they pay the price in licenses, training, and complexity.”

Previously, that was a rational compromise. To get CRM, email, booking, landing pages, and more working together, a big platform was the only practical option. Integrating many small tools was messy, brittle, or simply not possible.

AI changes that calculus. Leadership teams can now reasonably ask: “Do we really need this giant platform? What if we could assemble only what we need and wire it together? What if we could adjust flows without waiting on vendor roadmaps?”

Sitting with a mid-size services company last year, they put it bluntly: “We use maybe 15% of our current marketing suite. We keep it because tearing it out feels scary.” As AI-assisted integration improves, that fear barrier starts to drop.

The strength of all-in-one — “we do everything” — has quietly turned into a liability in an era where modularity is easier, integration is smarter, and custom building is cheaper. This aligns with the broader composable enterprise trend that Gartner has been tracking.

Composable SaaS: From Product to Custom Structure

Composable SaaS is a modular software approach that lets companies combine only the specific functions they need into a tailored system. Becker’s central claim is that SaaS isn’t disappearing — it’s mutating from all-in-one product to composable structures assembled per business.

The practical pattern looks like this: start with open-source templates or base frameworks, plug into existing tools for CRM, booking, forms, or analytics, use AI to generate glue code and customize interfaces, and end up with a small, focused bundle that fits one company’s exact workflow.

Instead of “which single platform does everything?” companies start asking what the minimum set of components they actually need is, how to wire those together for their specific process, and how to adjust quickly as things change.

Experimenting with connecting off-the-shelf CRM APIs, booking widgets, and AI-generated dashboards shows that a basic, tailored “mini-platform” can be assembled in days rather than months. It lacks the polish of a mature SaaS product. But for a specific business, it can fit better and cost less. That tradeoff is starting to look attractive.

“SaaS is not dying — it is evolving from subscription products to ordered, customized software structures.”

This is a business model shift: from selling access to a standard product, toward designing and delivering custom structures built from reusable pieces. It parallels the idea of composable applications emerging in cloud-native design.

Every reduction in code generation cost lowers the barrier to bespoke tools. That trend only moves in one direction.

The Infrastructure Layer Paradox: Why API Companies Get Stronger

The infrastructure layer is the foundation stack providing core capabilities — payments, email delivery, SMS, servers, data storage — through APIs (Application Programming Interfaces). Becker argues this layer will gain, not lose, power in a composable-SaaS world.

Here’s the paradox: as front-end apps become cheaper to build, easier to customize, and more commoditized, the underlying infrastructure stays hard. It’s technically demanding, heavily regulated, and operationally unforgiving.

Think about what’s actually involved in a few critical back-end domains:

• Payments: Fraud detection, regulatory compliance, secure handling, global payment methods.
• Email at scale: IP reputation, spam avoidance, bounce handling.
• Data storage and processing: Durability, backups, latency management.

“Front-end software can drift toward free, but API-based infrastructure companies may become even stronger.”

Companies will happily assemble their own UIs and workflows. But they’ll still rely heavily on rock-solid APIs underneath. Building a simple payment UI with AI is trivial. Building a compliant, battle-tested processing backend is not. That’s why platforms like Stripe and SendGrid have become foundational to so many stacks.

In Becker’s view, the survivors in this landscape fall into two groups:

• Companies where complex data and accuracy are central — analytics, tracking, finance, critical operations.
• Companies providing API infrastructure others plug into — payments, messaging, storage, identity.

Even as SaaS at the interface layer becomes more modular and disposable, these back-end services become more entrenched. That’s counterintuitive, but it holds.

A New Business Model: Framework Design and Custom Assembly

Framework design and custom assembly is an emerging service-plus-software model where providers build a reusable framework, then tailor and assemble it for each client. Becker’s recommendation to founders: stop chasing “the next giant all-in-one platform” and start building frameworks plus consulting-driven assembly.

The core idea is straightforward. Don’t try to replace entire categories with a monolith. Design a flexible framework that integrates existing tools. Offer a high-touch service that assembles and customizes it per client.

A typical project might look like this:

1. Select existing tools: CRM, booking, email, SMS, payment processors.
2. Design a structure that orchestrates data flow between them.
3. Interview the business owner — where is the biggest friction? Where are conversions getting stuck?
4. Assemble the system: wire the tools together, use AI to customize forms and flows.
5. Deliver the finished structure and train the team.

“The future SaaS model shifts from selling features to designing the most effective structure for each company.”

The revenue model is clean: an initial build fee, then an ongoing monthly subscription for maintenance, updates, and incremental improvements. Crucially, companies aren’t buying this to save on license fees. They buy it because they want a system that matches their business exactly.

From advising smaller agencies, this model also reduces dependence on a single vendor roadmap, creates stickiness through deep process integration, and tends to produce higher-margin, relationship-driven work.

The real barrier here isn’t technical skill. It’s consulting ability — understanding what the client truly needs. Domain knowledge — knowing an industry’s real bottlenecks. And system design skill — knowing which tool combinations actually work in the wild.

As AI keeps pushing implementation cost down, knowing what to build and how to structure it becomes more valuable, not less.

Where to Stand Now: Practical Implications and Strategy

Strategic positioning in this shifting landscape isn’t optional for anyone involved in software — platform operators, new founders, and enterprise buyers alike. Becker frames the next year or two as a particularly intense window of market reconfiguration. This is where it gets concrete.

For existing all-in-one SaaS companies, the risk is customer realization: “We can build enough ourselves.” As AI-driven natural-language app building becomes normal, buyers may opt to assemble lighter, custom stacks instead. Churn can accelerate fast if vendors don’t respond with more modular, flexible offerings.

For new founders and developers, rebuilding another heavy platform in a crowded category is increasingly risky. Designing frameworks and offering assembly-as-a-service may offer a lower barrier and clearer differentiation. Deep expertise in a specific vertical — healthcare clinics, coaching businesses, logistics brokers — becomes a genuine competitive edge rather than a nice-to-have.

For companies buying software, the key question shifts. Not “which SaaS has the most features?” but “which structure best fits our real-world workflow and data flows?” Working with providers who understand your domain and can assemble custom systems may yield better ROI than adopting the next mega-suite.

“The future SaaS winners will not just be great coders — they will be the best problem understanders and structure designers.”

The most impactful client projects I’ve been part of were rarely “we added another feature.” They were “we redesigned how leads flow, how teams hand off work, and how dashboards surface what actually matters.” The software changed. But more importantly, the structure did.

Becker’s message isn’t pessimism. It’s an invitation to reposition ahead of the curve — away from pure product thinking, toward structural design, modular assembly, and infrastructure leverage.

Frequently Asked Questions

Q: Does Alex Becker literally mean SaaS will disappear?

A: No. His argument is that SaaS in its current, all-in-one, product-selling form will struggle. He expects it to evolve into composable, custom-assembled structures where value comes from design and integration, not from owning a massive monolithic platform.

Q: Is AI-driven coding really not the main threat to SaaS?

A: In Becker’s view, AI-driven coding is a background change, not the core threat. SaaS was never primarily protected by coding difficulty — capital and teams could always be assembled for good ideas. The real threat is that AI reduces build cost enough that custom, composable alternatives become viable substitutes for bloated all-in-one platforms.

Q: What is “customer dependency” in the context of SaaS?

A: Customer dependency is the extent to which customers rely on a SaaS product for their core workflows and data. Becker’s Hyros example shows that the real moat is when customers integrate their data, processes, and teams so deeply that switching becomes painful. Features alone don’t guarantee this — careful onboarding, workflow fit, and results clarity do.

Q: How is composable SaaS different from traditional SaaS?

A: Traditional SaaS offers a single, multi-feature platform intended to serve many use cases at once. Composable SaaS uses modular components — existing tools, APIs, templates — and assembles them into a custom structure tailored to each business. The value shifts from feature breadth to structural fit.

Q: Which types of companies are most likely to thrive in this new model?

A: Becker highlights two main winners. First, companies where complex data and accuracy are mission-critical — advanced analytics, tracking tools. Second, API-based infrastructure providers for payments, email, SMS, and storage. Service businesses that design frameworks and custom-assemble tools for specific industries can also build strong positions.

Conclusion: SaaS Is Evolving from Products to Structures

The most important takeaway from Becker’s “SaaS is dead” thesis isn’t that software subscriptions are over. It’s that the center of gravity is moving.

From coding difficulty to customer dependency as the true moat. From all-in-one suites to lean, composable structures that match each business. From selling generic features to designing, assembling, and maintaining tailored systems.

For founders and builders, the opportunity is in understanding specific industries more deeply than competitors, mastering tool ecosystems and API infrastructure, and becoming architects of systems rather than just creators of apps.

For buyers, the opportunity is to demand more: less unused feature bloat, more alignment with real workflows, more flexibility to change and extend over time.

SaaS isn’t dying. It’s shedding one skin and growing another. Those who learn to think in structures — not just products — will be best positioned to own the next wave of software value.