For two decades, the software industry rested on a stable assumption: software was expensive to build and even more expensive to maintain, so companies should buy standardized products and share development cost across many customers.
That was the economic foundation of SaaS. A vendor built once and sold subscriptions repeatedly; customers traded some customization for lower cost, faster deployment, and continuous upgrades.
AI changes that assumption. Natural language can now produce interfaces, services, data transformations, and automated workflows. A domain expert working with AI can create in hours or days what once required a project team. Software gains a rare new property: it can be generated quickly, then discarded or rewritten just as quickly.
I call this disposable software.
“Disposable” does not mean deleting production systems every day or ignoring quality, security, and data. It describes a new cost structure. For many local, low-risk, fast-changing needs, software no longer has to be treated as a five-year asset designed for everyone. It can serve one team, one customer, one campaign, or one decision cycle. When the need changes, rebuilding may be cheaper than preserving layers of compatibility.
SaaS's real competitor is not another SaaS product
Traditional SaaS competition is framed around features: more capabilities, a better interface, more integrations, or a lower price.
After AI, the real competitor may be the customer's own ability to build.
An internet company once bought separate systems for tickets, approvals, dashboards, sales assistance, content operations, and knowledge management. Every purchase required selection, contracts, implementation, training, permission configuration, and migration. Even when deployment succeeded, the company adapted its work to the software's predefined model.
In the future, companies may retain a small number of stable systems of record—finance, people, customer master data, and core transactions—then generate many lightweight applications above them:
- a customer workspace for one sales campaign;
- a budget and resource flow for a new project;
- a campaign tool needed for only three months;
- a delivery and analytics interface for one customer type;
- an operating dashboard rewritten as strategy changes;
- a temporary diagnostic tool for an exceptional process.
These tools do not need to become standalone SaaS products or satisfy every company's shared requirements. They need to understand one organization's data, permissions, language, and workflow, then perform reliably for a limited lifetime.
SaaS is no longer competing only with peer vendors. It competes with whether customers can now build something good enough themselves.
Why generic SaaS gets harder
SaaS will not disappear, but thin SaaS will struggle—especially products that wrap a simple workflow in a generic interface, rely primarily on per-seat pricing, and own no critical data or transaction entry point.
Features are easier to reproduce
A niche capability once required months of engineering and created a meaningful product window. Interfaces, CRUD operations, reports, notifications, permissions, and baseline AI can now be assembled rapidly. Features still matter, but features alone make a weaker long-term moat.
Standardization can become an extra cost
To serve more customers, generic SaaS accumulates configuration, roles, templates, and compatibility paths. Customers receive a system that can fit many companies, but not necessarily one that fits their work.
When customization becomes inexpensive, standardization is no longer automatically cheaper. Process change, training, and configuration maintenance are costs too.
Seat pricing conflicts with agentic work
Software charged per person because each person logged in and operated it. When agents execute work under the supervision of fewer people, value moves from access to completed outcomes. Pricing every human seat becomes harder to justify.
Buyers recalculate build versus buy
Companies will compare three years of subscriptions, implementation, and migration with building on top of existing data and model capabilities. This does not mean they always build. It means SaaS must create value clearly beyond the AI-assisted internal alternative.
When I say “SaaS cannot raise,” I do not mean there is literally no money
When I say SaaS companies increasingly cannot raise, I obviously do not mean investors have stopped funding software altogether. The money is still there, and AI companies are still receiving very high valuations. But for most ordinary SaaS founders, fundraising is no longer a path they can assume will be available.
The old habit was to build a product, tell a growth story, raise a round, and use the next round to keep searching for the real business model. That path is becoming much harder. The important change is not whether capital exists, but why anyone should give it to you.
A generic SaaS company once raised on market size and a growth story, then searched for durable unit economics later. Today, lower development barriers, crowded categories, and expanding model platforms make investors ask earlier:
- Why can the customer not build this internally?
- Why will a model platform not include it?
- What proprietary data, distribution, or transaction relationship exists?
- Does growth require continuously buying traffic and adding sales headcount?
- How much gross margin is consumed by inference, human service, and custom delivery?
- If financing stops, can customer revenue keep the company alive?
What I actually mean is: generic SaaS without real revenue, differentiated assets, or a way to survive beyond the next round will become increasingly difficult to keep alive.
Funding can accelerate a business model that already works. It should not be the business model itself.
SaaS startups must relearn how to support themselves
AI lowers product development cost and therefore lowers the necessity of outside capital. What once required a large team and millions of dollars may now be tested by three to five people.
The first objective can be revenue again: find a specific and painful problem, earn payment, cover people and model cost, then decide whether to expand.
Self-funding does not mean refusing capital. It turns funding from a survival requirement into a strategic choice:
- the company can continue serving customers without a round;
- capital accelerates growth that has already been validated;
- free-user counts do not hide a lack of willingness to pay;
- feature expansion is not used to prove the product still matters;
- the next fundraising deadline does not force an unnatural scale target.
As software gets cheaper, small and profitable is not a consolation prize. It may be a healthier company design.
Internal software moves from project to capability
Traditional internal systems are built as projects: approval, requirements, scheduling, development, acceptance, launch, and a long maintenance tail. The system inventory grows while the organization becomes increasingly afraid to change it.
AI-native internal software behaves more like a continuous capability. Business people describe the problem, product-engineering defines boundaries, agents read approved company context and generate a working flow or interface, and the team validates it in real use before modifying or rebuilding it.
The future enterprise stack may have three layers:
| Layer | Typical contents | Lifecycle |
|---|---|---|
| Stable systems of record | Identity, finance, customers, contracts, transactions, core data | Years; tightly governed |
| Shared capability layer | Permissions, model gateway, data APIs, audit, deployment, components | Continuously evolving |
| Situational application layer | Workspaces, approvals, analysis, operations tools, customer-specific flows | Days to months; rebuildable |
The third layer is what becomes disposable—not the ledger, permissions, or core data.
The stronger the stable foundation, the faster situational applications can change. Enterprise investment shifts from buying more interfaces toward governing data, permissions, APIs, models, and institutional knowledge.
Custom no longer has to mean outsourced customization
Custom software once implied a costly outsourced project: thick specifications, long delivery, unmaintainable code, and a new quote for every change.
AI-enabled customization is different. It looks like the organization continuously writing software for itself:
- using its own data semantics and permission model;
- involving the people who actually use the tool;
- reusing an internal platform instead of restarting every time;
- controlling risk through automated tests, audit, and deployment;
- allowing low-value tools to retire naturally instead of maintaining them forever.
Professional engineers still own architecture, platforms, security, and high-risk systems. But many situational tools will be produced by domain experts, product engineers, and AI together.
Code is no longer the only scarce input. Domain understanding, reliable data, clear accountability, and judgment about what deserves to exist become more scarce.
Disposable must not mean software garbage
As generation gets cheaper, software sprawl becomes the obvious new failure mode. The ability to generate a tool does not grant it permission to touch production data or exist indefinitely.
Companies need boundaries:
- Data: minimum access required for the task;
- Identity: no bypassing centralized login, permissions, or offboarding;
- Release: checks proportional to production risk;
- Audit: records of who initiated important actions, what the model did, and what happened;
- Ownership: an owner, usage scope, and retirement condition for every tool;
- Reuse: repeated capabilities move into the platform rather than being copied dozens of times.
Disposable should mean inexpensive iteration and exit—not low quality, invisibility, or missing accountability.
Which SaaS products retain durable value
AI will not bring all software inside the enterprise. Several SaaS categories may become more valuable.
Systems of record and transaction networks
Finance, payments, contracts, identity, supply chain, and industry transaction systems represent trusted records, rule enforcement, and external networks—not merely an interface.
Deep industry data and decisions
Products that understand domain semantics, accumulate proprietary high-quality data, and influence consequential decisions are difficult to replace with a temporary generated app.
Security, compliance, and accountable delivery
When customers buy auditability, compliance, reliability, and responsibility—not just features—a specialist vendor can retain economies of scale.
Foundations for customer-generated software
The most valuable SaaS products may stop prescribing a fixed interface. They will provide APIs, data models, permission systems, agent capabilities, and composable components on which customers generate their own way of working.
SaaS does not disappear. It shifts from selling a fixed application to providing trusted capabilities that customers cannot easily reproduce.
What this means for companies and founders
Companies should not treat AI adoption as one more software subscription. The deeper task is developing internal software-generation capability: organizing data and APIs, building a safe foundation, pairing domain and engineering judgment, and letting low-value tools exit quickly.
Founders should no longer assume that implementing a feature creates a company. They must answer earlier why customers will keep paying, what cannot be reproduced by model platforms or internal teams, and whether the company can operate without the next round.
Product and engineering work also shifts from completing assigned modules toward understanding problems and delivering outcomes. As code gets cheaper, problem definition, systems judgment, data governance, and commercial understanding get more expensive.
Value moves from code to context
Industrialized software sought to build once and copy infinitely. Disposable software seeks to make each generation fit the current problem.
Companies will keep buying software, but they will question standardized products that contain interfaces and workflows without differentiated data or network value. They will preserve stable foundations while generating more short-lived, contextual applications internally.
Startups can no longer assume financing is the default fuel. Customer revenue remains the most reliable capital, and the strongest moats are no longer code volume but real workflows, trusted data, distribution relationships, and accountable delivery.
When software can be rewritten at any time, the assets worth accumulating are no longer every line of code, but context, data, trust, and judgment.
Disposable software is not the end of software value. It is a chance to turn a large class of software from assets that demand permanent care into tools that appear with a business need and retire gracefully when their work is done.
References
- Carta: How the SaaS fundraising scene is shifting in the age of AI: SaaS funding has not disappeared, but stage, round, and AI positioning are reshaping capital allocation, making the literal “no funding” claim inaccurate.
- OpenAI: Univé builds an AI-ready workforce: employees created many custom GPTs around internal workflows and increasingly solved operational problems without relying on long software projects.
- Microsoft: 2025 Work Trend Index: the report describes human-agent teams and agents entering business processes, providing context for internal software shifting from fixed applications toward composable capability.