Build vs. Buy Is Dead — Now There's a Third Option

Last month, I needed a simple dashboard to track content performance across a few channels. Nothing fancy — just pull some data, show some charts, let me filter by date range. The kind of thing a SaaS product would charge me $30 a month for, per seat, forever.

Instead, I described what I wanted to Claude, iterated on the output for about two hours, and deployed a custom tool that does exactly what I need. (I took a similar approach when building Smalltalk — a full SaaS product, shipped in weeks rather than months.) No login screen I will never redesign. No features I will never use. No monthly invoice.

That experience broke something in my head. Not because the tool was better than the commercial alternative — it was roughly equivalent. But because the effort was so low that paying for the commercial version started to feel irrational. And I realized: if this is how I am starting to think, millions of other people are too.

The Old Calculus

For decades, "build vs. buy" was the foundational framework for every software decision in business. The logic was clean:

Buy when the problem is generic, the vendor has domain expertise, and your engineering time is better spent on core product. Build when the problem is unique to your business, competitive differentiation depends on it, or vendor lock-in is too risky.

The framework worked because it rested on a stable assumption: building software is expensive and slow. A custom internal tool might take a team of engineers weeks or months. The total cost of ownership — development, testing, maintenance, iteration — almost always exceeded the subscription fee for an off-the-shelf product. So companies bought. A lot. The average enterprise now runs over 300 SaaS applications, according to BetterCloud.

This was rational. It made sense when the cost of building was measured in engineer-months and six-figure consulting contracts. But that cost structure is collapsing.

The Collapse

Retool's 2026 Build vs. Buy Report, surveying 817 builders across industries, found that 35% of teams have already replaced at least one SaaS tool with a custom-built alternative, and 78% expect to build more custom tools this year. The categories under the most pressure are telling: workflow automations (35% replacement rate), internal admin tools (33%), BI and analytics dashboards (29%), CRMs and form builders (25%), and project management tools (23%).

Notice the pattern. These are not complex, deeply integrated systems. They are, at their core, CRUD applications with a user interface — tools that create, read, update, and delete records, wrapped in a reasonably pleasant UI. They are the SaaS products that thrived precisely because building them used to be annoying enough that paying someone else to do it was worth it.

AI changed the denominator. When 51% of Retool's respondents have already shipped production software using AI, and 31% report prompting their way to complete applications, the "building is hard" assumption that propped up the entire SaaS market for these categories simply no longer holds.

Klarna became the poster child for this shift in early 2025 when CEO Sebastian Siemiatkowski announced the company had eliminated roughly 1,200 SaaS tools and built a custom AI-powered internal stack. Their customer service query resolution time dropped from 11 minutes to two. The tech press treated it as radical. But the underlying logic was straightforward: Klarna had the engineering talent, the data, and the AI tools to build exactly what they needed. The old calculus — is it cheaper to buy? — flipped.

The Third Option: Generate

This is not just a shift from "buy" to "build." That framing undersells what is happening. What is emerging is a third category entirely: generate.

"Build" implies a team, a backlog, sprints, maintenance. "Generate" implies something different — describing what you want and having an AI system produce it, often in hours rather than weeks. The distinction matters because "generate" dramatically expands who can create software. It is not just engineers replacing SaaS with custom code. It is product managers, analysts, operations leads, and founders producing bespoke tools without writing a line of code themselves.

As Marty Cagan argued in his Silicon Valley Product Group analysis, "the programming language is now English, which opens these capabilities up to nearly anyone with a problem to solve." Tools like Lovable, Bolt, and Replit are making this tangible — they are, as Cagan put it, some of "traditional SaaS's most visible challengers."

The irony is thick. SaaS was supposed to democratize access to software. Now AI is democratizing the ability to create software, which undermines the SaaS value proposition at its foundation.

But this expansion comes with a shadow. Retool's data reveals that 60% of builders have created tools outside IT oversight in the past year, with 25% doing so frequently. The old "shadow IT" problem — employees adopting unauthorized SaaS tools — is mutating into something potentially more dangerous: shadow development, where AI-generated applications proliferate without governance, security review, or maintenance plans.

What Survives

Not everything is vulnerable. The products most exposed are those whose value proposition is essentially "we saved you the trouble of building this yourself." When that trouble approaches zero, so does the willingness to pay.

But some categories have structural defenses that AI cannot easily replicate:

Network effects. Slack is not valuable because it is hard to build a chat application. It is valuable because your colleagues are already on it. Figma's moat is not the vector editor — it is the multiplayer collaboration and the plugin ecosystem. AI can generate a chat app in an afternoon. It cannot generate your organization's communication graph.

Proprietary data and compliance infrastructure. Stripe's value is not its API design (though that is excellent). It is the regulatory relationships, fraud models trained on billions of transactions, and PCI compliance infrastructure accumulated over fifteen years. Bain & Company's research on agentic AI disruption emphasized this point: companies should "leverage proprietary data as competitive moats, protecting transaction histories and domain-specific content from external AI platforms."

Deep workflow integration. Salesforce may be mocked for its complexity, but that complexity is also a moat. When a product is embedded across an organization's data flows, approval chains, and reporting structures, replacing it is not a matter of generating a better UI. Even Klarna's CEO, after his high-profile SaaS purge, admitted: "I don't think it is the end of Salesforce; might be the opposite." He was being honest about the difference between replacing a simple tool and replacing a deeply entrenched system.

Bain's framework for this is useful. They map SaaS workflows along two dimensions: AI's capacity to automate user tasks, and AI's ability to penetrate existing SaaS workflows. The products in the danger zone are those where both dimensions score high — routine, rules-based tasks delivered through relatively shallow integrations. The survivors are platforms where the workflow complexity and data gravity create genuine switching costs.

The Pricing Crisis

The disruption is not just about replacement. It is also about how the economics of software itself are being renegotiated.

The per-seat pricing model — the financial engine of SaaS for two decades — is under existential pressure. As Andreessen Horowitz noted, when AI handles the work that humans used to do with software, "the natural pricing metric becomes successful outcomes" rather than the number of humans using the tool. Companies that once needed 500 customer support licenses can achieve the same throughput with 50 licenses and a fleet of AI agents.

Deloitte predicts that by 2026, SaaS applications will evolve toward "a federation of real-time workflow services," with subscriptions and seat-based licensing giving way to hybrid approaches blending usage-based and outcome-based pricing. Wall Street is already pricing this in — a historic sell-off in early 2026 wiped over $1 trillion in market capitalization from the software sector, driven largely by fears that the seat-based model is unraveling.

This is not theoretical. It is showing up in earnings calls, in VC funding patterns where AI-native startups are outpacing traditional SaaS firms, and in procurement conversations where enterprise buyers are asking a question they never asked before: "Why are we paying per user for something an agent can do?"

What Comes Next

So where does this leave us? I think the honest answer is: in an uncertain middle.

The "SaaS is dead" take is wrong. Marty Cagan's counterpoint is persuasive: enterprise software encodes "thousands of often complex business rules, and millions of lines of business logic" addressing policy, compliance, security, and legal requirements. Most AI-generated tools do not account for these. A product manager who prompts an AI to build a customer database is unlikely to think about GDPR data residency requirements, SOC 2 audit trails, or edge cases in currency conversion for international invoicing. SaaS vendors who have spent years encoding this institutional knowledge have real, durable value.

But the "everything is fine" take is also wrong. The ground is shifting beneath a large portion of the SaaS market — the portion that was always more commodity than platform, more convenience than necessity. Bain calls it a "fundamental discontinuity comparable to cloud migration 25 years ago." Deloitte warns that over 40% of agentic AI projects could be cancelled by 2027 due to unanticipated cost and complexity, suggesting the transition will be messier and slower than the hype implies. But the direction is clear.

For founders, the implications are stark. Competing on features — on having a slightly better UI or a slightly faster workflow — becomes less defensible by the month. The new moats are data, community, and deep integration. If your product's value can be replicated by a well-crafted prompt, you do not have a product. You have a feature that is waiting to be absorbed.

For buyers, the framework I would suggest is this:

Buy when the product embeds domain expertise, regulatory compliance, or network effects that would take years to replicate.
Generate when the need is specific to your workflow, the data is yours, and the tool is simple enough that maintenance is minimal.
Build when the problem is core to your competitive advantage and requires ongoing investment from a dedicated team.

The old binary is dead. What replaces it is not another binary but a spectrum — and learning to navigate that spectrum is going to be one of the defining skills of the next decade of business technology.

I keep thinking about that dashboard I built. It works fine. It does exactly what I need. And every month, it silently saves me $30 that used to go to a SaaS company that assumed I would never bother building my own.

They were right about that assumption, for a long time. They are not right about it anymore.