AI is already changing the answer to “is SaaS dead because of AI?”—but not in the simplistic, all-software-is-doomed way social posts often suggest. A recent example from a glass business is more useful: it shows how AI can turn a paid point solution into a small internal capability when the underlying workflow, data, and technical owner are already in place.

The story came from a post in r/SaaS, where a user described replacing a paid cut-list optimization tool with a feature built into the company’s bespoke job-management system. The company selects jobs, chooses glass types, and receives cutting layouts and waste estimates without manually re-entering dimensions into a separate product. The claimed build time was extraordinarily short; the strategic lesson is not. (reddit.com)

CutList Optimizer itself describes its product as panel-cutting optimization software that creates cutting patterns by nesting required parts into available stock sheets. That is a legitimate and valuable task, especially for businesses without internal software capacity. But it is also exactly the kind of bounded, rules-driven function that can become easier to recreate when AI coding tools lower the cost of building custom workflow software. (cutlistoptimizer.com)

The cut-list story is not proof that SaaS is dead

The headline version of this story is seductive: a business stopped paying a SaaS vendor because an AI assistant generated a replacement. That is a real form of disruption. One customer can leave, and many similar customers can eventually do the same.

But the deeper point is narrower. AI did not eliminate the need to optimize material usage. It did not make glass dimensions, stock-sheet sizes, kerf allowances, inventory, job scheduling, or operational accountability disappear. It made it cheaper for one company to move a specific capability inside the software it already owns.

That distinction matters because “SaaS” is a delivery model, not one uniform product category. A lightweight calculator, an enterprise system of record, an API infrastructure provider, a collaborative workflow platform, and a regulated vertical operating system may all charge subscriptions, but they face very different exposure to AI-assisted replacement.

The cut-list case is best understood as a case of feature unbundling and reintegration:

  1. A company had operational data in its own job-management system.
  2. It used a separate tool for a narrowly defined optimization task.
  3. Employees had to transfer information between systems.
  4. AI lowered the effort required to build the optimization logic and user interface internally.
  5. The internal version was more useful because it removed duplicate data entry.

The displaced product was not necessarily bad. In fact, the SaaS product may have been the rational choice until an internal alternative became cheap enough. Its vulnerability came from being a separate destination for a task that could be embedded in the customer’s existing workflow.

What AI actually changed in this example

The important change was not that AI invented a new cutting algorithm. Packing and nesting problems have long been studied in operations research and industrial software. A cut-list application normally needs to arrange required rectangular pieces across stock panels or sheets while minimizing waste, respecting dimensions and constraints, and presenting a result that a worker can follow.

The AI shift is that a technically curious operator can now describe the business problem in natural language, generate an initial implementation, iterate on the interface, and connect it to an existing codebase far faster than before. The user in the Reddit discussion described using Claude to create an integrated version based on a bin-sorting approach rather than continuing to pay for a standalone utility. (reddit.com)

The model reduced implementation friction

Before generative coding tools, an owner with a good idea still had several expensive hurdles:

  • translating shop-floor requirements into a specification;
  • finding a freelancer or agency;
  • explaining the existing database and workflow;
  • waiting through design and development cycles;
  • reviewing bugs and edge cases;
  • paying again for changes.

AI does not erase those steps. It can, however, compress the gap between “I know what my process needs” and “I have a rough working version.” That is particularly significant for internal tools where a polished onboarding flow, broad compatibility matrix, billing system, documentation portal, and generic configuration layer are unnecessary.

Integration created more value than the algorithm

The Reddit thread’s strongest observation came from the commenters: the core value was not necessarily the optimization routine. It was the removal of double entry between the cutter’s tool and the order database.

That is a crucial correction to the common “AI cloned a SaaS” narrative. The custom version won because it had privileged access to the company’s orders, products, dimensions, and job selection process. The company was not merely copying a feature; it was eliminating an awkward boundary between two systems.

A standalone tool can be excellent at a discrete job and still lose to an internal feature when the customer’s workflow is unusually specific. AI makes these integrations more attainable, which means a product’s addressable market can shrink even if its core capability remains useful.

The SaaS categories most exposed to AI replacement

Not every SaaS product is equally vulnerable. The most exposed category is a tool that is simple enough to reproduce, detached from the customer’s source-of-truth data, and expensive relative to the perceived effort of rebuilding it.

1. Single-purpose calculators and generators

Products that transform a small set of inputs into a predictable output are exposed when customers can reproduce the logic in a spreadsheet, script, no-code workflow, or AI-generated internal app.

Examples can include basic estimators, document formatters, internal report generators, simple data converters, narrow planning tools, and form-to-PDF workflows. The risk rises if the product’s differentiator is a simple interface around logic that is well understood or easily approximated.

That does not mean these products have no market. Many buyers prefer a maintained, familiar tool over building and owning even a tiny internal application. But their pricing power is increasingly challenged by customers with enough technical confidence to customize.

2. Tools that force manual re-entry of business data

A SaaS product becomes easier to replace when users must export, copy, upload, or retype records from the systems where work actually begins. Every transfer is a tax on the workflow—and an invitation to build a direct integration.

The cut-list example is powerful because dimensions already existed in a job-management system. Once the optimization could run where those records lived, the separate tool stopped saving time. It introduced another step.

3. Thin interfaces over generic capability

Some software businesses depend on a generic model, public API, open-source library, or straightforward rules engine while adding only a small wrapper. If customers can access the underlying capability directly and tailor it to their own process, the wrapper may become hard to defend.

This does not imply that all “AI wrappers” fail. A focused product can still earn its place through high-quality workflow design, trusted outputs, proprietary data, approval controls, integrations, and service. But a wrapper with no meaningful workflow ownership has little room for error.

4. Internal-use software with no network effect

If a product serves one person or one department, does not coordinate external parties, and has few compliance or uptime requirements, an internal alternative may be practical. The buyer may conclude that a one-time build plus occasional maintenance is cheaper than recurring subscriptions.

The exposure is lower when the tool is shared across customers, vendors, partners, auditors, or a large distributed workforce. In those situations, the vendor is often providing more than the screen in front of the user.

Why most companies will not simply vibe-code their SaaS stack

The community reaction to the Reddit post contained the necessary skepticism. Several commenters pointed out that the initial build is not the whole product. Who hosts it? Who tests it? Who fixes errors? Who handles security? What happens when a staff member needs a new feature, the creator leaves, or the calculation produces a costly wrong answer?

Those questions are not anti-AI talking points. They are the dividing line between a useful internal prototype and durable operational software.

A working demo is not a production system

A three-minute build claim may describe the time needed to create a first version of a feature, not the time needed to establish confidence in it. In a glass-cutting workflow, an inaccurate calculation could waste costly material, delay a job, or cause a delivery problem. In other domains—payroll, healthcare, tax, payments, identity, security, or compliance—the consequences can be much greater.

A production-ready internal feature needs clear requirements and acceptance criteria. It may need input validation, audit logs, backups, role-based access, monitoring, tests against known jobs, graceful error handling, documentation, source control, and a person who is accountable for changes.

AI can help with maintenance, but it does not own accountability

The original poster argued that the tool was simple enough for Claude to diagnose if something failed. That may be a sensible judgment for a small, noncritical workflow owned by someone with hobby-level programming experience. It becomes less reliable as the software becomes more connected, more valuable, and more used by others.

AI coding tools are increasingly paired with security and code-quality checks rather than being treated as a substitute for review. GitHub, for example, has added automated validation for code produced by coding agents, while Anthropic has written about sandboxing and isolation as safeguards for agentic coding workflows. Those product directions reinforce the real lesson: AI can accelerate building and fixing software, but responsible teams still design controls around what the model produces. (github.blog)

The true calculation is total cost of ownership

The right comparison is not “monthly subscription versus one prompt.” It is:

Total cost of internal ownership = build time + review + hosting + maintenance + support + security + error risk + opportunity cost.

For a narrow optimizer embedded in an existing application, this number can be very low. For a tool used by hundreds of people, tied to sensitive data, or expected to evolve continuously, it can be substantial.

A SaaS vendor spreads those costs across many customers. The customer building internally takes them on alone. AI changes the balance by reducing the first component—development effort—but it does not automatically remove the rest.

The real SaaS moat is moving from interface to workflow control

The most useful takeaway for founders is not “add a chatbot.” It is that the old moat of being the place where users click buttons is weaker when an AI agent can generate screens, scripts, and integrations on demand.

A stronger moat is controlling the authoritative workflow: the trusted data, permissions, rules, records, integrations, and execution paths that make an action real. A cutting layout is useful, but a system that knows which jobs are approved, which glass is in stock, which machine can handle the cut, what the margin will be, and whether a supervisor has signed off is much harder to replace with a quick clone.

A 2026 market update from Houlihan Lokey makes a similar distinction in vertical software, arguing that domain workflows, proprietary data, and deep integration into customer operations can create structural advantages for systems of record. That view is more realistic than declaring an entire category dead: AI increases pressure on shallow tools while raising the value of software embedded in operational reality. (cdn.hl.com)

Durable SaaS value usually comes from several layers at once

The products least likely to be displaced by a quick internal build tend to combine multiple forms of value:

  • System-of-record data: The product holds authoritative customer, operational, financial, or compliance records.
  • Workflow orchestration: It coordinates tasks across teams, systems, and deadlines.
  • Deep integrations: It connects reliably to the tools customers already use.
  • Permissions and governance: It defines who can see, approve, change, and export information.
  • Domain expertise: It encodes complicated industry rules, edge cases, and best practices.
  • Trust and liability management: It provides security, support, uptime, contracts, and a responsible vendor.
  • Network effects or ecosystem value: It links buyers, sellers, developers, partners, or data contributors.

A model can help reproduce parts of these layers. Reproducing all of them, maintaining them, and earning user trust is a different project.

What the Reddit community got right—and wrong

The discussion around the post split into two familiar camps. One group argued that a single-feature utility with no meaningful integrations is “cooked.” Another argued that most businesses still pay for software because they do not have the development skills, time, or desire to own it.

Both positions contain truth.

The “single-feature SaaS is vulnerable” argument is right

If a product provides one small transformation, requires manual input, and is not tightly integrated with downstream work, customers have a growing menu of alternatives. They can use AI-assisted coding, spreadsheets, automation platforms, freelancers, or existing systems with a new feature.

The customer does not need to become a professional software company to make that choice. They only need enough capability—or access to a sufficiently inexpensive builder—to make the specific problem cheaper to own than to rent.

The “software ownership is work” argument is also right

The dismissive claim that a business could “just hire a freelancer once” ignores the full lifecycle of useful software. A freelancer can deliver code, but someone must own the requirements, test releases, control access, respond to failures, preserve institutional knowledge, and decide what happens next.

For many businesses, buying SaaS remains rational because the vendor specializes in those obligations. The value of a subscription is not always the complexity of the code. It may be the certainty that the service will be available, improved, supported, and usable by the next employee.

The more accurate conclusion: AI changes make-versus-buy thresholds

AI does not force every customer to build. It lowers the threshold at which building becomes sensible.

In the past, a company might buy a $50-per-month tool because even a small custom feature required a developer, a project plan, and a several-thousand-dollar budget. If AI lets a technically capable operations lead create and validate that feature in days rather than weeks, the economics change.

This pressure will be greatest among customers that already have:

  1. a bespoke internal application or an accessible codebase;
  2. clean operational data in one place;
  3. a workflow that is genuinely different from the vendor’s generic product;
  4. a technically inclined owner or trusted contractor;
  5. a narrow, low-risk use case; and
  6. a financial reason to avoid recurring spend.

That is a meaningful segment, but it is not every business buyer.

A practical test for founders: could a customer absorb your product?

Founders should ask a deliberately uncomfortable question: if a capable customer had access to AI coding tools and one motivated internal champion, could they absorb our most valuable feature into their own system?

If the answer is yes, the product may still be viable—but the go-to-market and roadmap should reflect that reality. Charging purely for access to a replaceable function becomes harder. The opportunity is to become the safest, fastest, most connected way to produce a business outcome.

Run the absorption test

Evaluate your product across these six dimensions:

  1. Algorithm uniqueness: Is the core logic truly difficult, data-rich, or continuously improving—or is it a known approach that can be approximated well enough?
  2. Data dependency: Do users need to import data manually, or does the product own or deeply connect to their source-of-truth records?
  3. Workflow breadth: Does the software solve one moment in a workflow, or coordinate the process before and after it?
  4. Operational burden: What maintenance, uptime, security, and support would a customer inherit by rebuilding it?
  5. Cost of an error: Is an incorrect output a minor inconvenience, a material loss, a compliance breach, or a safety issue?
  6. Customer capability: Do target customers have developers, technically sophisticated operators, or agencies that can build alternatives?

A product with low algorithm uniqueness, weak integrations, narrow workflow scope, low error costs, and technical customers is in the most exposed zone. That does not require panic. It requires a plan.

Build features that make the product harder to remove

There are several productive responses to this shift:

  • Move closer to the system of record through integrations, APIs, imports, webhooks, and embedded workflows.
  • Store valuable historical data that helps customers make better decisions over time.
  • Offer review, approvals, versioning, exception handling, and auditability—not just generation.
  • Invest in domain-specific templates and outcome benchmarks rather than generic functionality.
  • Price around business value or completed work where appropriate, not only per seat or per superficial feature.
  • Make extensibility a feature: let customers customize the last mile without replacing the whole product.

In other words, do not make customers choose between your rigid standalone interface and building everything themselves. Give them a platform that can adapt while preserving the difficult parts you operate well.

What buyers should build internally—and what they should keep buying

For operators, the lesson is not to cancel every subscription and tell an AI assistant to recreate the stack. The better strategy is a portfolio approach: build the highly specific edges of your workflow, buy the commodity infrastructure and high-risk systems, and integrate both deliberately.

Good candidates for AI-assisted internal tools

An internal build is often worth testing when the problem is bounded, the data is already available, and a mistake is easy to detect or reverse. Examples include internal dashboards, custom estimators, report assemblers, routing aids, document preparation, task triage, specialized data entry screens, and rules-based calculations.

The best starting point is usually the work employees currently do in spreadsheets, email threads, copy-and-paste sequences, or a disconnected point tool. These are places where custom context can matter more than a large vendor’s generic feature set.

Poor candidates for a casual internal build

Be more cautious where the software handles money movement, highly sensitive information, legal obligations, safety-critical decisions, customer identity, broad external collaboration, or round-the-clock availability expectations. These are not impossible to build, but they demand mature engineering and operating practices.

The same applies to infrastructure capabilities that appear simple only because a specialist has already absorbed enormous complexity. Email delivery is a useful example: an application can send a message with a small amount of code, while dependable delivery at scale requires authentication, deliverability management, bounce handling, reputation protection, suppression logic, observability, and compliance. The visible feature is rarely the whole service.

A lightweight validation checklist

Before replacing a paid tool, run the proposed internal version through real historical cases and document the results. Give the effort an owner, a fallback process, and a simple change log. Decide explicitly who can deploy changes and who can approve modifications to business rules.

You should also quantify the savings honestly. If a tool costs $100 a month but needs 20 hours a year of maintenance from a valuable employee, cancellation may not be a win. If it costs thousands per year, blocks a critical workflow, and can be safely absorbed in a day or two, the calculation looks different.

AI will create more software, not necessarily less software

The phrase “SaaS is dead” misses a paradox: when software becomes cheaper to produce, organizations usually create more of it. They build more custom tools, automate more small decisions, and tailor more processes to their own data.

That does not necessarily increase demand for every existing SaaS subscription. It does increase demand for reliable foundations: databases, identity, payments, communications, observability, deployment, security, integrations, and systems that coordinate work across an organization.

The market may therefore split in two. On one side are disposable or locally built applications: small interfaces that solve a narrow problem for one business. On the other are platforms and vertical systems that provide durable operational infrastructure. The middle—generic, disconnected, lightly differentiated tools—faces the sharpest pressure.

This is why the cut-list case should not be read as a story about AI replacing all software vendors. It is a story about software becoming more composable. The company did not stop using software. It moved one capability to a different layer of its stack, closer to the data and workflow where it created the most value.

The bottom line: SaaS is not dead, but standalone utility pricing is under pressure

So, is SaaS dead because of AI? No. But some SaaS products are becoming easier to replace, especially when they are isolated, single-purpose utilities that make customers manually bridge the gap between the tool and their own operations.

The glass cut-list example is credible precisely because it is modest. A motivated user with an existing internal system replaced a bounded optimization feature and made it better for that company through direct integration. That does not mean every customer can, should, or will do the same. It does mean founders cannot assume a simple user interface around a well-understood function is a permanent moat.

The winners in the AI era will not merely generate more code. They will own trusted workflows, reduce operational burden, integrate deeply, make complex decisions safe, and let customers customize without forcing them to become full-time software maintainers. For buyers, the opportunity is to selectively internalize the parts of work that are uniquely yours—and continue buying the difficult systems that are better operated as a service.

FAQ

Is SaaS dead because of AI?

No. AI is lowering the cost of building and customizing software, which puts pressure on isolated utilities and thin wrappers. SaaS remains valuable where it provides operational reliability, integrations, governance, domain expertise, trusted data, and ongoing maintenance.

What kinds of SaaS products are most vulnerable to AI?

The most vulnerable products tend to be single-feature tools with little proprietary data, few integrations, low error costs, and workflows that customers can reproduce inside existing systems. Simple calculators, generators, and disconnected internal utilities are more exposed than systems of record.

Can Claude or other AI tools really replace a SaaS product?

They can help a technically capable user build replacements for narrow use cases. The resulting tool still needs validation, deployment, maintenance, security controls, and a person responsible for its outcomes. AI reduces build friction; it does not eliminate software ownership.

Why was the cut-list tool replaceable in this example?

The company already had job and product data in bespoke management software. By placing the optimization function inside that system, it removed manual data entry and tailored the result to its own workflow. The integration created more value than a separate standalone interface.

Should SaaS founders worry about customers building their own tools?

They should treat it as a strategic design constraint, not an automatic death sentence. Founders should deepen integrations, own harder workflow layers, support customization, add governance and reliability, and price around the measurable business outcomes their product delivers.