click here to subscribe for information on upcoming articles before they are released and periodical summaries of the most read articles.

Random Thoughts on Leadership & Technology

The End of Build vs Subscribe Dilemma

build-vs-buy

How AI Is Dissolving the Oldest Question in Enterprise Software

"The best software is the software you don't have to write."

Prologue: A Question as Old as the Industry Itself

In 1968, NATO convened a conference in Garmisch, Germany to address what attendees called the "software crisis" - the growing recognition that building reliable software was extraordinarily hard, expensive, and slow. The debate that emerged from that conference seeded a question that would haunt enterprise technology decisions for the next six decades: should organizations build their own software, or acquire it from specialists?

This question has shapeshifted across eras. In the 1970s and 80s, it was build vs. buy - do you write the payroll system yourself, or license IBM's? In the 1990s, it became build vs. package — SAP, Oracle, and PeopleSoft offered pre-assembled enterprise suites that promised to standardize and accelerate. In the 2000s, Salesforce changed everything again with the cloud, and by the 2010s, the question had evolved once more into build vs. subscribe - why manage infrastructure when you can pay monthly for Slack, Workday, Zendesk, or a hundred other SaaS applications?

Each transition was a tectonic shift. Each one produced new winners, destroyed old incumbents, and forced enterprises into agonizing procurement debates.

We are now living through a fourth transition - and this one is different in kind, not just degree. AI is not moving the needle on the build-versus-subscribe spectrum. It is erasing the spectrum itself.

Part I: A Brief History of the Dilemma

1.1 The Custom-Code Era (1960s–1980s)

For the first two decades of commercial computing, "build" was the only real option. Software was bespoke, written by in-house teams of programmers who were often closer to mathematicians than engineers. The American Airlines SABRE reservation system, built in partnership with IBM and launched in 1960, cost roughly $40 million (over $400 million in today's dollars) and took seven years. It was, by necessity, entirely custom.

The logic of this era was straightforward - software was so novel, so organization-specific, and so tied to proprietary hardware that external acquisition was rarely coherent. You built because there was nothing to buy.

The risks were enormous. The U.S. Department of Defense's 1987 report on software acquisition found that of $6.8 billion spent on custom software, only 2% worked as delivered. The build option was expensive, slow, and riddled with failure — but it was the only one available.

1.2 The Packaged Software Revolution (1980s–1990s)

The IBM PC changed the economics of software distribution. For the first time, a program written once could run on millions of machines. Companies like SAP (founded 1972, but dominant in the 1980s and 90s), Oracle, and PeopleSoft built the first great argument for "buy" - why reinvent the general ledger when SAP R/3 already had it?

The ERP wave was not gentle. It forced organizations to make an uncomfortable trade - surrender competitive differentiation in back-office processes in exchange for speed, reliability, and lower development cost. The phrase "best practices" became the euphemism for "you must change your business to fit our software."

The consulting industry was born from this compromise. McKinsey, Accenture, and Deloitte grew enormous practices around a single problem - helping enterprises configure generic packages to approximate their unique needs. The cost savings of "buy" were often consumed by implementation fees. SAP implementations that promised 18-month timelines routinely stretched to four years. Hershey's famously botched its SAP go-live in 1999, failing to ship $100 million worth of candy during Halloween season.

And yet, the argument for buy held. The alternative - building your own ERP - was far worse.

1.3 The SaaS Subscription Revolution (2000s–2010s)

Marc Benioff launched Salesforce in 1999 with a provocateur's simplicity - "No Software." The core insight was not just that software could live in the cloud, but that the customer relationship with software could be fundamentally restructured. Instead of a capital purchase - a depreciating asset on the balance sheet - software became an operating expense, a monthly subscription, infinitely scalable and someone else's problem to maintain.

The SaaS model solved real problems:

By the mid-2010s, the SaaS ecosystem had exploded. The average enterprise in 2015 used roughly 8 SaaS applications. By 2022, according to BetterCloud research, that figure had risen to over 130. Venture capital flooded into vertical SaaS - software purpose-built for dentists, for trucking companies, for restaurants, for legal practices. The "build vs. subscribe" question seemed settled - for anything that wasn't a true competitive differentiator, you subscribed.

The SaaS decade produced extraordinary wealth. Salesforce, Workday, ServiceNow, Veeva, HubSpot, Zoom, Slack — the market caps were staggering. The formula was elegant - find a business process, build a multi-tenant platform, charge per seat, grow net revenue retention above 120%, and watch the Rule of 40 metrics sing.

Part II: The AI Disruption — Why This Time Is Different

2.1 The Arrival of the General-Purpose Reasoning Engine

Every prior shift in the build-vs-buy landscape was driven by changes in distribution and economics. Packaged software distributed code more cheaply. SaaS distributed it more elastically. But in both cases, the underlying labor equation remained constant: skilled human programmers were required to write software, and that labor was scarce and expensive.

Large Language Models have begun to alter this foundational assumption.

GitHub Copilot, launched in 2021, was the first mainstream demonstration that AI could write syntactically correct, contextually appropriate code at a pace no human could match. By 2023, Copilot users reported completing coding tasks 55% faster in controlled studies. By 2024, Anthropic's Claude, OpenAI's GPT-4, and Google's Gemini had demonstrated the ability to produce not just code snippets but entire functioning applications from natural language descriptions.

The implications are profound and not yet fully absorbed - if the cost of writing software falls dramatically, the entire economic argument for subscribing to someone else's software begins to collapse.

This is not a marginal change. It is a categorical one.

2.2 The Three Forces Blurring the Line

Three converging forces are dissolving the build-vs-subscribe boundary simultaneously.

Force 1: AI-Accelerated Development

The most direct force is simple - AI makes building dramatically cheaper and faster. A startup today can build a functioning CRM prototype in hours using Claude or Codex, not months. A mid-size enterprise with a modest engineering team can now tackle projects that previously required an army of developers.

Consider what this does to the calculus. Historically, a company evaluating whether to build a custom contract management system might estimate:

The math almost always favored subscribe. But if AI compresses the build timeline from 18 months to 3, and reduces the required engineering headcount by 60–70%, the build cost might drop to $300K. Suddenly the comparison is: $300K one-time (with perfect fit to your process) versus $200K/year in perpetuity (with the compromises of a generic platform).

Force 2: The Rise of AI-Native "Instant Software"

Beyond accelerating traditional software development, AI is enabling an entirely new category: software that is generated on-demand, customized per user, and disposable when no longer needed. We are beginning to see early versions of this in tools like Replit, Vercel's v0, Lovable, and Anthropic's own artifacts feature.

The concept - sometimes called "vibe coding" or more seriously "prompt-to-application", sometimes branded also as "agentic engineering" - represents a paradigm where the distinction between "using software" and "building software" collapses. A financial analyst who describes, in plain English, exactly the kind of data dashboard she needs and receives a functioning application within seconds is neither building nor subscribing. She is summoning.

This is not science fiction. It is happening today, at the prototype level, and the trajectory of improvement is steep.

Force 3: AI Agents as Software Substitutes

Perhaps the most structurally threatening development for SaaS businesses is the emergence of AI agents that can perform the functions of software without requiring the software itself.

A traditional SaaS customer relationship management system does several things - it stores contact data, tracks interactions, surfaces insights, automates follow-up, and generates reports. An AI agent, given access to a company's email, calendar, and document systems, can perform most of these functions without a dedicated CRM platform. The agent doesn't need a structured database if it can read and synthesize unstructured data. It doesn't need a workflow automation engine if it can reason about what to do next.

Salesforce recognized this threat explicitly. Their pivot to "Agentforce" in 2024 was not a product extension - it was an existential repositioning, an attempt to reframe themselves as the infrastructure layer for AI agents rather than a SaaS platform vulnerable to being disintermediated by them.

2.3 Historical Parallels - When Utilities Ate Products

The closest historical parallel may be what happened to enterprise computing infrastructure in the 2000s. Before AWS, every company that needed servers had to buy them, rack them, power them, cool them, and staff teams to maintain them. Data center management was a massive industry. Then Amazon made compute and storage into utilities - infinitely available, billed by the minute - and the entire market for on-premises server hardware for general workloads collapsed.

The SaaS giants that built their platforms on top of AWS did not fear this transition - they benefited from it. But the companies that sold the physical infrastructure that AWS replaced (Sun Microsystems, SGI, parts of HP) were largely annihilated.

The question now is - does AI make application logic into a utility the same way AWS made compute into a utility? If it does, the SaaS vendors that built application logic into packaged subscription products face the same fate as Sun Microsystems.

Part III: Why SaaS Businesses Are Threatened

3.1 The Structural Vulnerabilities of the SaaS Model

The SaaS business model is more fragile than it appears in periods of growth. Its elegance - recurring revenue, high gross margins, compounding net revenue retention — depends entirely on two conditions:

  1. Switching costs remain high. Customers stay because migrating data, retraining users, and rebuilding integrations is painful.
  2. The product cannot be replicated cheaply. The engineering moat justifies the price.

AI is attacking both conditions simultaneously.

Switching costs are declining. AI tools can extract, transform, and migrate data with increasing ease. Natural language interfaces mean users need less retraining. Integration layers built on AI can bridge systems without bespoke code. The "data gravity" that kept customers locked into Salesforce or Workday is becoming less gravitational.

The engineering moat is eroding. The features that took SaaS companies years and hundreds of engineers to build can increasingly be replicated by a smaller team in a fraction of the time. This is not to say that all SaaS products can be replicated overnight - but the marginal cost of feature parity is declining faster than any SaaS business model assumed when it was designed.

3.2 The Seat-Based Pricing Crisis

SaaS pricing is almost universally based on seats - the number of human users of the system. This made perfect sense when software was used by humans. But AI agents don't need seats. They don't log in the way a person does. They access systems through APIs.

As enterprises increasingly deploy AI agents to do work that humans previously did - reading emails, updating records, generating reports, filing tickets - the seat count drops. The SaaS vendor's revenue shrinks even as the value delivered by the underlying data and platform may remain constant.

Salesforce's attempt to address this with "agent-based pricing" (charging per conversation or per task completed) signals that the industry recognizes the problem. But repricing a multi-billion-dollar business without destroying customer relationships or triggering churn is extraordinarily difficult. It is the innovator's dilemma in its purest form - the business model that made you successful is the same one that makes your future harder to navigate.

3.3 The Long Tail Collapse

The SaaS explosion of the 2010s was partly driven by the "long tail of software" - the recognition that every niche industry had inefficiencies worth automating. Hence - software for yoga studios, for veterinary clinics, for title companies, for food trucks. Vertical SaaS became a rich vein of venture investment.

These long-tail SaaS companies are the most immediately threatened by AI. They competed on specificity - knowing the quirks of the dental practice workflow better than a general-purpose product. But AI can learn a specific workflow from a detailed description. A general-purpose AI system, properly prompted and given appropriate context, can handle the scheduling, billing, and patient communication needs of a dental practice without a purpose-built SaaS product.

The long tail of SaaS - hundreds of companies serving niche markets - faces potential obsolescence not from larger competitors but from AI's ability to address specificity without specialization.

3.4 The Data Moat Question

The one asset SaaS companies confidently cite as defensible is their data. Salesforce knows more about how salespeople work than any AI startup. Workday's datasets on HR processes are unmatched. Veeva's pharma industry data is irreplaceable.

This argument has merit - but it is weaker than it sounds.

First, the data itself is largely the customer's data, not the vendor's. Regulatory trends (GDPR, the EU AI Act, emerging U.S. state privacy laws) are reinforcing customers' rights to their own data and making it harder for vendors to use customer data to train models without explicit consent.

Second, foundation model providers - Anthropic, OpenAI, Google — are training on vast corpora that capture enormous amounts of general business process knowledge, diminishing the advantage of any single vendor's proprietary dataset.

Third, and most importantly - data is only a moat if it produces better outcomes. If a competitor's model, trained on general data and fine-tuned briefly on a customer's specific data, produces outcomes within acceptable quality range of the incumbent's proprietary-data model, the moat is shallow.

Part IV: Not All SaaS Dies - The Survivors

4.1 The Infrastructure Layer Will Strengthen

There is a critical distinction between application-layer SaaS and infrastructure-layer SaaS. Companies that provide the pipes - cloud platforms, data warehouses, identity management, networking, security - are not threatened by AI in the same way. In fact, AI workloads increase demand for infrastructure.

AWS, Azure, Google Cloud, Snowflake, Databricks, CrowdStrike - these businesses provide the substrate on which AI runs. They are the railroads of the AI economy. You cannot disintermediate a railroad by building a faster train - the train needs the railroad.

Snowflake's pivot to positioning itself as an AI data platform rather than just a cloud data warehouse is a textbook example of reading the room correctly. Their data-sharing and governance infrastructure becomes more valuable in a world where AI agents need governed, trustworthy access to enterprise data.

4.2 Products with Deep Workflow Embeddedness

Some SaaS products are so deeply embedded in organizational workflows - with integrations, customizations, compliance configurations, and institutional muscle memory accumulated over years - that the theoretical replication cost is less important than the practical switching cost.

ServiceNow, for example, is not just a ticketing system. For many enterprises, it is the operational nervous system: the place where IT incidents, HR requests, legal workflows, and security events are managed, escalated, and resolved. The switching cost is not just technical - it is organizational and procedural. These products retain a durable moat even as AI reduces the theoretical cost to replicate them.

4.3 Regulated, Compliance-Critical Software

Certain software categories are protected by regulatory moats that AI cannot easily bypass. Healthcare record systems must be HIPAA-compliant and maintain certified audit trails. Financial reporting software must align with GAAP, IFRS, and SOX requirements. Electronic trading systems must meet SEC and FINRA standards.

These compliance certifications take years to obtain and require ongoing maintenance. An AI-generated application cannot instantly acquire FDA 21 CFR Part 11 compliance. The regulatory moat is real and durable - though it too will eventually yield as AI systems themselves become certified and regulated.

Part V: Predictions for the Future of Enterprise Software

5.1 The Era of Composable Intelligence (2025–2028)

The immediate future belongs to a hybrid model: enterprise software that is neither purely subscribed nor purely built, but composed. Organizations will subscribe to AI platforms (foundation model APIs, orchestration frameworks, data infrastructure) and use those platforms to assemble custom applications continuously.

Think of it as the difference between buying a piece of furniture from IKEA (subscribe to a complete product) and buying materials from a lumber yard to build exactly what you need (build from components). The current moment is the emergence of an AI lumber yard - platforms like Anthropic's Claude API, LangChain, Microsoft Azure AI Foundry - from which software can be quickly constructed.

Prediction: By 2028, the majority of Fortune 500 companies will have internal or partner operated "AI software factories" - small, elite teams of AI-fluent engineers and product managers who build and iterate on custom applications 10–20x faster than traditional development shops. These teams will not replace SaaS entirely but will reclaim the customization that SaaS forced them to abandon.

5.2 The Great SaaS Consolidation (2026–2030)

The SaaS market, which produced thousands of venture-backed companies over the past fifteen years, will undergo significant consolidation. The category of "$5–50M ARR SaaS companies serving a narrow workflow" is the most vulnerable. Many will be acquired by larger platforms seeking to absorb their specialized data and customer relationships before AI commoditizes the functionality.

The winners of this consolidation will be:

Prediction: Between 2026 and 2030, we will see the M&A elimination of at least 40% of current SaaS companies with less than $100M ARR, either through acquisition, acqui-hire, or shutdown. The "death by a thousand SaaS tools" era will give way to ruthless portfolio rationalization driven by AI-capable alternatives.

5.3 The Rise of the AI-Native Enterprise Software Category (2027–2032)

A new category of enterprise software will emerge that has no direct predecessor. Call it orchestration platforms or enterprise AI operating systems. These are products that manage, govern, and optimize the portfolio of AI agents that an enterprise deploys - tracking what agents are doing, ensuring compliance with data policies, measuring business outcomes, managing costs.

Today's rudimentary versions of this category include tools like Langfuse, Weights & Biases, and early agent management features in Salesforce and ServiceNow. But the mature version will be as important to the 2030s enterprise as the ERP was to the 1990s enterprise.

Prediction: By 2032, "AI Operations" (AIOps, distinct from today's usage of that term) will be a recognized enterprise function with dedicated budget lines, and the platforms that serve it will be a $50B+ market.

5.4 Pricing Models Will Shatter and Reassemble

The seat-based pricing model that defined the SaaS era will not survive the decade intact. We will see a proliferation of pricing experiments:

This transition will be messy and contentious. Enterprise procurement teams are not equipped to evaluate outcome-based software contracts. Legal frameworks for SLAs tied to business outcomes are immature. The transition period will produce significant friction between vendors and customers.

Prediction: By 2030, fewer than 30% of enterprise software contracts (by value) will be purely seat-based. The rest will incorporate some form of consumption, outcome, or capability-based pricing.

5.5 The Re-Emergence of the Strategic Build Decision

Paradoxically, the era of cheap AI-assisted building will prompt enterprises to revisit which software truly represents competitive advantage - and to intentionally build more of it.

In the SaaS era, the "subscribe to everything non-core" orthodoxy became a blanket policy. It was good advice when building was expensive. But if building is cheap and fast, the question "is this a competitive differentiator?" matters more. Amazon didn't subscribe to an e-commerce platform. It built one. Goldman Sachs didn't subscribe to a trading system. It built one. The organizations that treated software as a competitive weapon, not a cost center, gained durable advantages.

As AI lowers the cost of building, more companies will correctly identify software as a competitive weapon in their specific domain and invest in building it. The orthodoxy will shift from "subscribe unless it's truly core" to "build anything that differentiates you, and subscribe only to commodities."

Prediction: By 2030, the largest enterprises will have materially larger internal AI engineering teams than they have today, despite — or because of — the availability of powerful AI tools. The marginal return on internal software investment will have risen, not fallen.

Part VI: The Deep Irony

There is a profound irony lurking in all of this that deserves acknowledgment.

The SaaS companies that are now threatened by AI were themselves the great consolidators of an earlier era. They displaced internal IT departments. They made the old argument that custom software was a fool's errand, that specialized vendors could always do it better. They were, in many cases, right for their time.

Now the disruptors are being disrupted by tools that, in some sense, restore the primacy of the individual organization's specific needs. The arc of software history is bending back toward specificity - not the expensive, artisanal specificity of the custom-code era, but a new, AI-enabled specificity that is fast, cheap, and continuously adaptive.

This is how disruption usually works - the new technology does not simply replicate the old at lower cost. It enables a fundamentally different relationship between the technology and the user. The printing press didn't just make manuscripts cheaper - it changed who could author and who could read. The internet didn't just make libraries faster - it changed who could publish. AI doesn't just make software cheaper - it is changing who can build, what can be built, and what "software" means as a concept.

We are moving, perhaps, toward a world where software is less a product and more a capability - not something you buy or build in a discrete moment, but something that continuously crystallizes around your needs, adapts to your context, and dissolves when no longer useful.

Epilogue: The Question That Remains

The NATO conference of 1968 identified a software crisis rooted in complexity. The solution, over sixty years, was specialization - let the experts write the software, let the organizations subscribe to it. That solution produced extraordinary value and extraordinary wealth.

The new crisis is different. It is not a crisis of complexity - AI handles complexity with increasing grace. It is a crisis of fit - the recognition that generic software, however sophisticated, can never perfectly serve the specific, evolving, idiosyncratic needs of a specific organization.

AI may be giving organizations something they have always wanted but could never afford: software that is exactly right for them, built at the moment they need it, by people who understand their business rather than by engineers who must reduce their business to a configuration menu.

The build-vs-subscribe dilemma is ending. Not because one side won, but because the distinction is losing its meaning. What replaces it - the continuous, AI-assisted crystallization of organizational capability into functioning software - has no good name yet. AIvolution?

Naming it will be the work of the next decade. Here is your chance to coin a term 😀