SaaS won because it was better than the alternatives.
Most companies did not buy SaaS because every product perfectly matched the way they worked. They bought it because building custom software was slow, risky, expensive, and hard to maintain. SaaS converted a capital project into a subscription, shifted maintenance to a vendor, and gave teams a working product now instead of a requirements document later.
That was a good trade.
It was still a compromise.
Companies accepted generic workflows. They accepted vendor data models. They accepted feature gaps. They accepted admin complexity. They accepted roadmap dependency. They accepted that the last mile of the process would happen in spreadsheets, meetings, emails, exports, and side conversations.
AI does not erase the reasons SaaS exists. It changes the size and shape of the compromise.
What SaaS is still good for
A serious build strategy starts by respecting what vendors do well.
Buy when the process is mature, common, regulated, integration-heavy, or operationally expensive to run. Buy when the vendor's scale creates quality you cannot economically reproduce. Buy when compliance, security, uptime, ecosystem access, and support matter more than bespoke workflow fit.
Good vendor categories include systems like:
- identity and access management;
- payroll and benefits;
- accounting and tax;
- CRM systems of record;
- billing and payments;
- security monitoring;
- data infrastructure;
- contract lifecycle systems;
- support ticketing;
- core HRIS.
These systems are not just screens. They contain rules, integrations, auditability, permissions, compliance posture, and years of edge cases. Rebuilding them because AI can generate code is not strategy. It is amateur hour with a nicer demo.
Where the compromise breaks
The compromise breaks at the workflow layer.
SaaS products are designed for many customers. Your operating advantage often lives in specifics: how you qualify accounts, route exceptions, onboard customers, inspect deals, approve discounts, prioritize support, manage launch readiness, or review renewal risk.
Vendors can support some of that. They rarely capture all of it cleanly.
So companies create a shadow layer:
- custom fields no one understands;
- spreadsheets that become unofficial products;
- Slack threads as workflow engines;
- dashboards manually refreshed before meetings;
- approval steps embedded in email;
- exports stitched together by one trusted operator;
- enablement docs that are actually business logic.
That layer exists because the purchased system is not the whole operating system. It is one component inside it.
The new build-versus-buy question
The old question was: should we build this system or buy it?
The better question is: which layer are we talking about, and who will own it after launch?
There are at least four layers:
- System of record. Where durable business objects live: accounts, contracts, employees, invoices, tickets.
- Workflow layer. How work moves across people, tools, approvals, exceptions, and decisions.
- Intelligence layer. Summaries, recommendations, prioritization, classification, research, and decision support.
- Experience layer. The interface users actually experience, which may cut across several systems.
Most companies should still buy many systems of record. More companies should build or configure more of the workflow, intelligence, and experience layers.
A useful decision rule is simple:
- buy the layer when the process is common, regulated, or operationally heavy;
- configure the layer when the vendor already has the right model but the setup is messy;
- extend the layer when the workflow is specific, cross-functional, and worth owning;
- do not build when ownership, policy, or maintenance is unclear.
That is where AI changes the economics.
Vendor strategy gets more important, not less
If you build more around vendors, vendor strategy matters more.
You need to know which vendors are stable platforms and which are closed applications. You need clean APIs, event streams, permissions, audit logs, sandbox environments, export paths, and contract terms that allow extension. You need to avoid vendors that trap data or punish integration.
The vendor question becomes: will this product be a durable system we can build around?
A good vendor becomes infrastructure. A bad vendor becomes a workflow prison.
The operator's rule
Do not replace SaaS because building is newly possible.
Replace or extend the parts where the generic compromise is creating measurable drag, where the workflow is specific enough to matter, and where you can own maintenance responsibly.
Buy the commodity foundation. Build the differentiated workflow. Be careful about confusing one for the other.
