In June 2026, Benedict Evans at Andreessen Horowitz published a clear argument: AI usage economics are changing the SaaS business model. The core point is straightforward — if AI significantly reduces the cost of building software, the entire premise of SaaS, that it’s cheaper to share development costs across many customers than to build custom, becomes less compelling in more use cases than it used to be.
This is not a theoretical concern. It’s a present-day strategic question that every enterprise technology leader should be working through with current numbers, not the numbers from four years ago.
flowchart TD
N[Software need] --> Q1{General-purpose?<br/>CRM, ERP, HR, security}
Q1 -->|Yes| BUY[Buy SaaS:<br/>economies of scale win]
Q1 -->|No| Q2{Narrow fit, heavy integration,<br/>or AI on proprietary data?}
Q2 -->|No| BUY
Q2 -->|Yes| MATH[Run the 3-year build math<br/>with AI-assisted capability]
MATH --> BUILD[Build in-house]
class BUY accent
class BUILD good
class Q2 accent
classDef good fill:#163a26,stroke:#44cc77,color:#d7ffe6;
classDef bad fill:#3a1620,stroke:#ff5555,color:#ffd9d9;
classDef warn fill:#3a2e16,stroke:#ffaa33,color:#ffe9c7;
classDef accent fill:#15233b,stroke:#4488ff,color:#dce9ff;
Why SaaS Won the Enterprise Market
SaaS won the enterprise software market in the 2010s for an obvious reason: building software is expensive, and amortizing that cost across thousands of customers made subscription pricing dramatically cheaper than custom development for most organizations. Salesforce, Workday, ServiceNow, and every tier of the SaaS ecosystem that followed them were built on the same economic premise — that custom enterprise software was too costly to justify except at the largest scale.
That premise was correct in 2015. It is less correct in 2026, and the delta matters for how you make software decisions.
What AI Changes About the Math
AI reduces the cost of software production significantly. The directional claim is well-supported across a range of use cases: AI-assisted development teams produce functional software faster than teams working without it, and the gap has widened as the tools have matured.
The math that follows is straightforward. If custom software development costs substantially less than it did four years ago, then the make-vs-buy threshold shifts. Software you would have purchased as SaaS in 2021 — because building it wasn’t economical — may now be buildable in-house at a cost that beats subscription pricing over a three-year horizon.
The interesting cases are in the middle: custom integrations, internal tools, workflow-specific applications, and industry-specific functionality that never fit cleanly in a horizontal SaaS product. These were almost always purchased previously because the build cost was prohibitive. That’s no longer automatically true.
What This Does Not Mean
It does not mean enterprise organizations should stop buying SaaS. The economies of scale, maintenance burden, and domain expertise that come with SaaS products are real, and the calculation still favors buying for most general-purpose enterprise software — CRM, ERP, HR systems, security infrastructure, and any domain where the vendor’s entire organization is focused on solving the same problem you’d be solving with a fraction of an engineering team.
What changes is the decision framework for specific categories:
Internal tools and operational software with no strong SaaS equivalent. If you’re paying for software that doesn’t quite fit your workflow and customizing it significantly to make it work, the build math is worth running.
Workflow automation requiring heavy integration. If implementing a SaaS product involves six months of integration work anyway, the delta between “buy and integrate” and “build to spec” has narrowed.
At a class-action settlement administration company, I was asked to tackle one of the hardest projects in the company: a returns processing and fulfillment workflow that sat on top of the United States Postal Service’s API surface. This was years before the current AI era, so there were no off-the-shelf models to lean on and no SaaS product that fit. The work was an orchestration problem — mail returns rules, status triggers, exception paths, and reconciliation against USPS interfaces that did not behave consistently across endpoints. The choice in front of the team was the same one that shows up in build-vs-buy conversations today: cobble together adjacent tools and hope the integration layer holds, or treat the workflow itself as the architecture and build to it.
I pushed for architecture first. Not speed of development, not proximity to a specific tool — the workflow itself, mapped end to end, before a meaningful line of production code went in. The argument was simple: computational workflows have an outsized impact on outcomes that is almost always underestimated at the start, and once foundational elements have taken shape around an under-specified flow, every later decision pays a tax. Had the organization gone the other direction, the project would have been slower and considerably more expensive. Because they committed to the architecture-first path, the entire returns processing and fulfillment system was rebuilt from scratch and ran at near 100% accuracy.
The lesson translates directly to the build-vs-buy calculation in 2026. When a SaaS product is going to require six months of integration work to fit a real operational workflow, the integration layer is the system. Treating it as glue around a vendor product almost always understates the cost. Treating the workflow as the thing you are actually building — and then making the make-vs-buy call against that — produces a more honest number on both sides.
Industry-specific applications. In industries with specialized workflows — legal, logistics, healthcare operations, financial services — available SaaS products often require substantial adaptation. That adaptation cost is real and frequently underestimated.
AI-native features involving proprietary data. If the competitive value is in what AI does with your specific data, building preserves control over that asset in ways that vendor-hosted solutions may not.
The Strategic Implication for Enterprise Technology Leaders
Enterprise technology leaders who aren’t revisiting their build-vs-buy frameworks are making decisions with outdated economics. The question is not whether to abandon SaaS — it’s whether your current portfolio of subscriptions, custom integrations, and internal tools was assembled with the cost structure that applied in 2022 or the one that applies now.
The related question is organizational: does your engineering team have the AI-assisted development capability to execute on a build decision when the economics favor it? This is not a given. Organizations with strong SaaS procurement disciplines and limited in-house engineering capacity face a genuine strategic gap. The answer is not necessarily to hire aggressively — it may be to develop the internal capability to design and manage AI-assisted builds without doing all the production work internally.
A Practical Starting Point
Organizations doing this well right now are running a portfolio exercise: map current SaaS spend against what each tool actually does in the specific organizational context, identify the categories where fit is poor or customization cost is high, then estimate what in-house development would cost with current capabilities against a three-year horizon.
This is not a full technical audit. It’s a strategic analysis that can typically be done in a few days with the right technology leadership involved. The output is a ranked list of make-vs-buy decisions worth reconsidering — not a blanket shift in strategy, but a deliberate revisiting of assumptions that were formed under different economics.
The companies that don’t run this analysis will continue making acquisition decisions with 2019 math. That gap compounds over time as the cost differential widens.
Reach out directly if you want to work through this analysis for your specific technology portfolio.
