For years, buying software was the sensible default for most enterprise workflows. A vendor could spread development costs across thousands of customers, while an individual organisation would struggle to justify building and maintaining its own CRM, service desk, approval system, or reporting layer.
Agentic coding tools are changing that calculation. They can help internal teams generate software around a company’s actual processes instead of forcing those processes into a generic product. The result is not the end of SaaS, but a more demanding procurement question: which capabilities should the organisation rent, and which should it own?
The evidence compiled for this analysis reports that 32% of organisations have decided against purchasing at least one software product because they believed they could build the functionality internally using agentic coding tools. Among organisations with more than $1 billion in annual revenue, 40% are scaling AI agents in at least one business function.
Those figures signal a change in behaviour, not proof that every company should start replacing its software vendors. Building is becoming more plausible. It is still easy to underestimate what ownership involves.
The economics of software procurement are moving
The traditional build-versus-buy calculation focused on development time, engineering salaries, implementation costs, and licensing fees. Agentic coding tools reduce some of the effort required to create interfaces, connect systems, write tests, and adapt software to internal rules.
That makes a tailored application viable in situations where a full product build would previously have been too expensive. A company may not need to recreate an entire CRM. It may only need a front end that gives sales staff the right customer view, applies its qualification rules, and writes approved updates back to existing systems.
A cost comparison cited in the evidence illustrates the scale of the potential difference. Hexaware estimates that an AI-accelerated custom CRM front end for 3,000 users could cost between $1.2 million and $2.0 million over three years, compared with $7.5 million to $13.5 million for traditional CRM licences. That is a substantial gap — but it is a model, not a universal result. The assumptions behind staffing, integrations, security, usage, and support need to be tested before it becomes a procurement decision.
A sensible build case therefore starts with a narrow workflow rather than a broad ambition:
- Identify the specific user task that creates cost or friction.
- Separate the workflow from the vendor product that currently hosts it.
- List the systems, data, permissions, and controls the workflow depends on.
- Estimate the three-year cost of both options.
- Test whether the organisation can operate the resulting system after the initial build.
For example, a distributor renewing a large CRM contract might discover that most users only need account search, opportunity updates, approval routing, and a small number of reports. A custom interface could improve those tasks without replacing the CRM’s underlying data store or every advanced feature. The decision is no longer simply “buy a CRM or build a CRM.” It becomes “buy the infrastructure we genuinely need and build the workflow where our process is distinctive.”
Which SaaS workflows are most exposed?
Agentic tools are not equally disruptive across all software categories. The greatest exposure is likely to be in products where the workflow is highly visible, repetitive, and closely tied to a company’s internal rules.
Consider a standard approval process:
- An employee submits a request.
- An agent checks the request against policy.
- The system routes it to the right approver.
- A finance or procurement system records the decision.
- Exceptions are escalated and logged.
If a SaaS product mainly packages this sequence with configurable screens and rules, an internal team may be able to reproduce a useful version around the organisation’s existing systems. The custom tool could remove unused features, reflect local terminology, and make exceptions easier to handle.
By contrast, the case for buying remains stronger where the product depends on specialised infrastructure, large-scale data operations, regulatory certifications, or an ecosystem that would be expensive to reproduce. Agentic AI can act as a reasoning and orchestration layer, but it does not remove the need for dependable identity management, data storage, observability, security scanning, backup, resilience, and compliance controls. For a deeper look at why AI agent projects fail in production without operational engineering, see our governance-focused analysis.
This distinction matters for procurement teams. A visible workflow is not the same thing as a simple system. A claims-processing interface may look straightforward while depending on complex fraud detection, audit requirements, document storage, and regulated decisions underneath.
SaaS vendors with high AI penetration and transparent process logic may face the most pressure because customers can see exactly what they are paying for and imagine recreating it internally. Vendors that provide difficult-to-replicate infrastructure, trusted data, specialised models, or strong governance may remain valuable even when the user experience around them becomes custom-built.
The hidden cost of choosing “build”
The first demo is often the least expensive part of an internal software project. AI coding tools can accelerate development without necessarily accelerating customer value, and they do not eliminate the obligations that begin when people rely on the software.
A serious three-year total-cost-of-ownership model should include:
- Initial design and development: requirements, architecture, testing, integration, data migration, and user acceptance.
- Operations: hosting, monitoring, incident response, release management, backups, and disaster recovery.
- AI usage: token consumption for development agents, production agents, evaluation, retries, and increasingly complex workflows.
- Security and compliance: access controls, vulnerability scanning, audit trails, secrets management, and periodic reviews.
- Change management: updates when regulations, vendor APIs, internal policies, or business processes change.
- People and continuity: the engineers and product owners who understand how the system works, including cover for absence and staff turnover.
Token costs deserve particular attention. A workflow that appears inexpensive in a controlled pilot may become costly when agents repeatedly inspect large records, call multiple tools, retry failed actions, or generate lengthy reasoning traces. Usage limits, caching, smaller models for routine steps, and clear escalation rules should be part of the design rather than afterthoughts.
The other risk is fragmented DIY infrastructure. A team may begin with one coding agent, add a separate orchestration layer, connect several model providers, store prompts in an informal repository, and rely on manual deployment. Each choice can seem reasonable in isolation. Together, they create a system that is difficult to secure, monitor, upgrade, or hand over.
The recommendation in the evidence is to prefer a unified AI platform over a collection of disconnected tools. The practical principle is broader: centralise the controls that must be consistent, even if individual business workflows remain customised. Identity, logging, evaluation, deployment, model access, permissions, and cost reporting should not be reinvented by every department.
A practical procurement rule
Before renewing a major SaaS contract, model the cost of retaining it, replacing only the high-friction workflow, and building a complete alternative. Include token usage, maintenance, security controls, integrations, and the people required to operate the result — not just the cost of generating the first version.
A workflow-first way to make the decision
A useful review can be completed in four stages.
1. Audit the actual work
Do not start with a list of software features. Observe how people complete the work today. Which steps are repeated? Where do employees export data to spreadsheets, copy information between systems, or wait for approvals? Which features are used weekly, and which are merely included in the licence?
Document the inputs, decisions, system calls, exceptions, and outputs. This exposes whether the organisation is paying for a full product when it mainly needs a smaller operational workflow.
2. Classify what must be owned
Some capabilities should remain with a trusted vendor: regulated infrastructure, security services, specialised databases, or functions where downtime would be unacceptable. Other parts may be candidates for internal ownership: tailored interfaces, routing logic, internal knowledge retrieval, or approval orchestration.
This produces a more useful hybrid question than “build or buy everything.” It asks which layer creates differentiation and which layer is safer to procure.
3. Run a bounded pilot
Choose one workflow with clear inputs, measurable cycle time, and a manageable risk profile. Define success before development begins. For a sales workflow, that might include faster account updates, fewer duplicate records, or better completion of required fields. For procurement, it could be shorter approval time without bypassing policy controls.
The pilot should include production-like data, permission testing, failure handling, and an operating owner. A polished demonstration without those conditions says little about whether the tool can be trusted.
4. Approve the operating model, not only the application
Before moving beyond the pilot, assign responsibility for releases, monitoring, security review, cost control, and user support. Decide how the organisation will respond when a model changes, an integration breaks, or the agent takes an ambiguous action.
The evidence indicates that enterprise-wide scaling is a multi-year effort, with an 18-to-36-month timeframe presented as an unverified claim rather than an established benchmark. Regardless of the exact duration, leaders should treat scaling as sustained operational work — not as a quick extension of a successful prototype.
What this means for enterprise buyers and SaaS vendors
For buyers, the strategic shift is from licence management to workflow ownership. A lower subscription bill is not enough to justify building. The organisation must be able to explain why the workflow is distinctive, how it will be governed, and who will maintain it when the original project team moves on.
For vendors, standard feature breadth may become less defensible when customers can assemble a focused alternative around their existing systems. Products will need to provide value through trusted infrastructure, data quality, security, specialised expertise, measurable outcomes, or capabilities that are genuinely difficult to reproduce.
The near-term outcome is likely to be selective unbundling rather than a universal SaaS collapse. Some companies will build interfaces and orchestration layers while continuing to buy core platforms. Others will retain a broad suite because operational reliability outweighs the savings from customisation.
Agentic coding tools have changed the threshold at which building becomes worth considering. They have not removed the discipline required to own software. The strongest procurement decision is therefore not the one that produces the most custom code. It is the one that matches each workflow to the right ownership model — and accounts honestly for what happens after launch.