The “SaaSpocalypse” is a wonderfully efficient piece of internet language. It compresses a complicated claim into one dramatic noun: AI can now build software, therefore a meaningful share of packaged software is headed for extinction.
There is some truth in it. The cost of challenging an established software category has fallen sharply. A team with a clear process and capable AI tooling can produce a convincing application much faster than it could a few years ago.
But there is an easy version of this experiment and a hard one. The easy version builds a dashboard. The hard version builds something whose mistakes have consequences.
So Buzzy chose sales incentive planning: software that combines CRM, ERP, HR, compensation rules, effective dates, approvals, reconciliation, disputes, and payroll-adjacent controls. A wrong number here is not a cosmetic bug. It is a conversation with a seller, a manager, and eventually finance.
The result is documented in the new technical whitepaper, Is the SaaSpocalypse Real? The short answer is: partly. AI can challenge a SaaS category faster than incumbents may find comfortable. It does not abolish the need for a governed application, nor does it make a giant pile of generated source code a particularly attractive replacement.
What did Buzzy build?
Using Buzzy Builder MCP through Codex, the team built a working Sales Incentives & Planning prototype in a few days. It included five role-specific experiences for sellers, managers, sales operations, finance, and executives; 29 managed and remote data tables; simulated CRM, SAP, HRIS, ERP, and analytics sources; live charts; approval and exception workflows; seller statements; and a commission calculation waterfall.
This was not a production Sales Performance Management suite, and the paper does not pretend otherwise. The data was synthetic. The prototype did not prove payroll accuracy, production-scale performance, full security hardening, or lower total cost over several years.
What it did provide was enough connected behaviour for stakeholders to argue about the right things. Which sales records count? Which plan version applies? How is an adjustment approved? Can finance reconcile the result? Can the seller see how the payout was produced?
That last question is a useful quality test. A commission calculation should survive a finance meeting. Returning a number is not the same as explaining it.
The important result was not time to first screen
Speed was expected. The more interesting result was where the application lived after it had been built.
In a conventional code-first build, requirements tend to disperse across components, routes, database migrations, services, tests, and the prompts used to generate them. The application works, but its intent becomes something a future team must infer.
In the Buzzy prototype, the durable structure remained visible as managed artifacts: a brief, process flows, a data model, a screen blueprint, permissions, workflow state, and explicit risk decisions. Custom code was used at the edges where it was useful—a deterministic mock integration service and specialised visualisation widgets.
The paper estimates that a conventional prototype with the demonstrated breadth would require roughly 50,000 to 129,000 lines of customer-specific code. The observable custom surface in the Buzzy prototype was approximately 2,900 lines: 932 lines in the synthetic data service and roughly 2,000 lines in chart and calculation-waterfall widgets.
These numbers are directional, not a benchmark carved into stone. They do not count Buzzy’s own platform implementation, because the useful comparison is what customer-specific code the delivery team must write and carry forward. They also do not prove lower operating cost. Platforms have costs, and production systems need hardening.
The architectural difference is still real: most of the ordinary application structure did not have to become bespoke code.
AI does not remove software work. It changes its location.
The common mistake in arguments about AI-built software is to treat code generation as though it deletes the rest of the software lifecycle. It does not.
NIST’s Secure Software Development Framework describes security practices that need to be integrated into the development lifecycle. Those obligations do not evaporate because an AI produced the first implementation. The 2025 DORA research reaches a related organisational conclusion: AI acts as an amplifier, magnifying the strengths and weaknesses already present in the system around it.
That is why the question is not simply whether AI can build an application. It can. The useful question is what form the organisation wants the application to take once the demonstration is over.
If every business rule becomes generated code, then every change becomes a code investigation. If the requirement, data model, workflow, access rule, and risk decision remain explicit, a broader group can inspect them while changes are still cheap.
The hard work remains. It just appears earlier, in a form people other than the original developer can challenge.
Sales incentive software exposes the difference
Salesforce currently lists Spiff Incentive Compensation Management at US$75 per user per month, billed annually, with additional connector and support options. Many other enterprise products in the category use quote-based pricing. The subscription price, however, is only one line in the real cost model. Implementations also have to reconcile source data, encode plan rules, manage historical changes, train users, and support disputes.
That complexity accumulated for a reason. Sales incentives sit across organisational boundaries. Sales owns the motivation, operations owns the process, finance owns the liability, HR owns sensitive people data, and IT owns the unpleasant surprises.
An AI-built alternative still has to respect those boundaries. The whitepaper’s proposed architecture keeps curated CRM, ERP, HRIS, and finance facts in governed enterprise data products; uses Buzzy for the application definition, user experience, workflow state, permissions, and governance; and reserves bounded services for specialised calculation execution.
This is not an attempt to replace the data warehouse, SAP, or payroll. It is an attempt to stop every new operational workflow from demanding a brand-new hand-built application shell.
So, is the SaaSpocalypse real?
Yes, in the limited but consequential sense that software categories can now be challenged much faster. Organisations can prototype around their own process before accepting every assumption embedded in a packaged product.
No, if the claim is that mature enterprise software has become trivial or that subscriptions can be replaced safely with a weekend’s worth of generated code.
The credible middle is less theatrical: AI plus a governed semantic application definition plus a small number of bounded custom services. Use AI to accelerate analysis and construction. Keep workflows, rules, data, permissions, and risk decisions visible. Write code where implementation is genuinely the differentiated part.
The practical next step is not a rip-and-replace announcement. It is a bounded pilot: define one workflow, test it against sanitised historical data, explain the variances, then harden access, audit, observability, integration, and operations for controlled production.
SaaS is not dead. But the assumption that every serious application requires a large, opaque, customer-owned codebase is looking considerably less healthy.