{"slug": "saas-isnt-dead-sameness-is", "title": "SaaS Isn’t Dead. Sameness Is.", "summary": "Gartner estimates that $234 billion in enterprise application software spending, roughly 20 percent of enterprise SaaS spending, is at risk from 'agentic arbitrage' by 2030, but the firm frames the shift as a metamorphosis rather than an apocalypse. The article argues that while companies will still pay for hosting, security, and support, the assumption that thousands of companies should use the same application will fade, predicting that the next SaaS company may run one service underneath ten thousand different applications.", "body_md": "Everyone suddenly wants to tell you SaaS is dead.\n\nThe Klarna-replaced-Salesforce story spread because it fit the mood, whatever the exact boundary between “replaced the CRM” and “consolidated the data underneath it” turned out to be. Agents are starting to do work that once required people clicking through applications. Seat-based pricing looks vulnerable when the seats themselves stop doing the work.\n\nEven [Gartner now estimates](https://www.gartner.com/en/newsroom/press-releases/2026-07-01-gartner-says-us-dollars-234-billion-in-enterprise-application-software-spend-is-at-risk-from-agentic-artificial-intelligence) that as much as $234 billion in enterprise application spending could be exposed to what it calls “agentic arbitrage” by 2030, roughly 20 percent of enterprise SaaS spending.\n\nBut Gartner itself hedges the apocalypse. It calls what is coming less an apocalypse than a metamorphosis.\n\nI think that’s right.\n\nAnd I want to make a more specific prediction about what SaaS turns into.\n\nCompanies will still pay other companies to host important software, secure it, operate it, maintain authoritative data, track regulatory changes, connect to external networks, and answer the phone when something breaks.\n\nWhat is much less obviously going to survive is the assumption that ten thousand different companies should use substantially the same application.\n\n**The next SaaS company may run one service underneath ten thousand different applications.**\n\nSuppose your company has an unusual sales process.\n\nTwenty years ago you had two realistic options.\n\nYou could buy a CRM designed for thousands of companies and configure it until it approximately fit the way you worked.\n\nOr you could build your own.\n\nThe second option sounded appealing until somebody calculated what “build your own” meant: developers, designers, product management, security, hosting, integrations, upgrades, migrations, support, on-call coverage, and years of maintenance.\n\nYou would spend millions building a worse version of something Salesforce already did, then own it forever.\n\nOf course you bought Salesforce.\n\nThe same logic played out across the enterprise. Companies bought SAP, Workday, Jira, ServiceNow, Oracle, and hundreds of other products, then gradually changed themselves to fit the software.\n\nA CRM has concepts for opportunities, stages, accounts, contacts, and forecasts. A project management system has issues, epics, sprints, statuses, and workflows. An HR system has its own model of employees, managers, organizations, approvals, and reviews.\n\nThese can be good abstractions. But they are still choices.\n\nOver time, the choices made by software vendors become the language of the organizations using them.\n\nWe tend to describe this as standardization or best practice. Sometimes it is.\n\nSometimes it is simply the result of an economic bargain:\n\nAdapting the organization to the software is cheaper than adapting the software to the organization.\n\nFor decades, that bargain was obviously correct.\n\nThe first copy of a serious software product was enormously expensive. The ten-thousandth copy cost almost nothing.\n\nSaaS turned that asymmetry into one of the best business models ever invented.\n\nSaaS did more than move applications into the browser.\n\nIt made sameness operationally valuable.\n\nThe vendor controlled the running system. Everyone could be upgraded. Security fixes rolled out centrally. Features shipped continuously. The vendor no longer had to support hundreds of customer installations that had been modified beyond recognition.\n\nThis produced one of enterprise software’s most durable maxims:\n\nConfigure, don’t customize.\n\nCustomization created forks.\n\nThe customer changed the software. Then the vendor changed the software. Somebody had to reconcile the two.\n\nRepeat that for several years and the customer ended up stranded on an ancient release with a pile of modifications nobody fully understood.\n\nConfiguration solved that problem by constraining variation. The vendor decided in advance which dimensions could differ: fields, permissions, workflow states, plugins, integrations, feature flags.\n\nCustomers could be different, but only in ways the product had anticipated.\n\nThat was an excellent compromise.\n\nBut it was not a law of software engineering.\n\n**“Configure, don’t customize” was a coping strategy for expensive code.**\n\nIf customer-specific software becomes cheap to produce and cheap to reproduce, that trade changes.\n\nImagine an internal approval process used by fifty people.\n\nIt is peculiar to one company because of two acquisitions, three jurisdictions, an old regulatory settlement, and a division of authority no sane product manager would ever design from scratch.\n\nToday the company probably buys a generalized workflow platform and spends months configuring it.\n\nNow imagine a small internal team can produce a purpose-built application in a few days.\n\nThe company’s identity system already exists. The necessary data is available through stable interfaces. Authorization rules are explicit. Hosting, observability, security, and deployment come from a shared platform.\n\nThe application does not need to appeal to five thousand other customers.\n\nIt does not need a roadmap.\n\nIt does not need a total addressable market.\n\nIt needs to solve this problem for these fifty people.\n\nThat changes what software is economically allowed to exist.\n\nFor most of software history, an application had to justify its production cost. Either enough people needed roughly the same thing, or the problem was important enough to justify bespoke development.\n\nAs production costs fall, the minimum viable market shrinks.\n\nOne organization. One department. Eventually, for some software, one person.\n\nThis leads to a strange possibility:\n\n**More software may mean fewer software companies.**\n\nAn insurance company might generate twenty highly specific internal applications next year and never release any of them publicly. If three replace existing SaaS contracts, the world contains more software and less commercial software spend at the same time.\n\nThat is a very different dynamic from the software economy we grew up with.\n\n“SaaS is dead” bundles together several different ideas.\n\nThe software is hosted by someone else. The vendor operates and secures it. The vendor maintains authoritative data, updates regulatory logic, handles migrations and integrations, and takes responsibility for availability and support. Customers pay for that capability over time.\n\nAnd historically, thousands of customers have also used substantially the same application.\n\nCheap generation attacks that last property much harder than the others.\n\nI don’t want to run my own payment network because an agent can generate a checkout page.\n\nI don’t want to maintain tax tables because an agent can build payroll screens.\n\nI don’t want every hospital generating its own authoritative interpretation of medical records.\n\nA lot of the value in modern SaaS has surprisingly little to do with the visible application.\n\nIt is data, trust, networks, compliance, operational responsibility, domain knowledge, auditability, accumulated history, and someone being accountable when reality gets complicated.\n\nAI can destroy the interface to a service while increasing demand for the service underneath it.\n\nThat is why the disappearance of seats or screens does not imply the disappearance of the vendor.\n\nThis matters for pricing too.\n\nTraditional SaaS pricing often maps neatly onto humans using applications.\n\nPer seat. Per user. Per agent.\n\nThat worked because the application was both the place where the work happened and the place where the vendor captured value.\n\nAgents weaken that link.\n\nA payroll provider does not become valueless because an employee stops opening its payroll interface. The customer is still paying it to calculate payroll correctly, keep up with tax law, move money, file with governments, maintain records, and accept operational responsibility.\n\nSo perhaps it increasingly gets paid for employees processed, money moved, filings completed, jurisdictions supported, or outcomes guaranteed.\n\nA payments company already charges around transactions rather than seats. A data company can charge around information, rights, volume, or usage. A security company can charge around protected assets, workloads, identities, or risk.\n\nA substrate company has to price the thing it actually supplies.\n\nThis will be painful for SaaS companies whose economics depend on selling access to screens that agents no longer need.\n\nIt may be excellent for companies whose real value was hidden behind those screens all along.\n\nThe easiest way to imagine the new model is to split the application into pace layers.\n\nAt the bottom are things we want to move slowly: identity and authority, authoritative data, audit history, core domain semantics, regulatory logic, security boundaries, external contracts, networks, money movement, and accumulated operational knowledge.\n\nThat last one matters more than it first appears.\n\n[Gartner argues](https://www.gartner.com/en/newsroom/press-releases/2026-07-01-gartner-says-us-dollars-234-billion-in-enterprise-application-software-spend-is-at-risk-from-agentic-artificial-intelligence) that useful agentic systems will need to retain deep institutional memory and customer context over time. Every exception resolved, correction made, policy interpreted, and operational failure understood can become part of the durable capability underneath the application.\n\nThe screens may be disposable while the institution underneath them gets smarter.\n\nAbove those slow layers are things that can move much faster: workflows, interfaces, reports, approvals, automations, dashboards, local policy, orchestration, agent behavior, and team-specific tools.\n\nToday’s SaaS product typically bundles both layers together and expresses customer differences through configuration.\n\nA generative SaaS company can operate the slow layer and generate much of the fast layer separately for each customer.\n\nThe vendor can still host everything. Still secure it. Still monitor it. Still control deployment. Still provide support.\n\nBut customer A gets one application, customer B gets another, and customer C may interact mostly through agents.\n\n**The software is bespoke. The service is shared.**\n\nThat is not the death of SaaS.\n\nIt is mass-customized SaaS.\n\nThere is an easy way to overstate this argument.\n\nSameness is not valuable only because variation was expensive.\n\nPeople join a company already knowing Salesforce or Jira.\n\nConsultants know how to implement them. A labor market forms around them. Integrations target them. Training and certifications exist. Answers are searchable. Thousands of customers discover bugs and edge cases together.\n\nA common workflow can also make an organization better by pushing it toward a practice that has already been learned elsewhere.\n\nThose effects are real.\n\nThe future is not “variation wins.”\n\nIt is:\n\nStandardize where sameness creates leverage. Generate where difference creates value.\n\nWhy should every business share a payment protocol? There are enormous advantages.\n\nWhy should two companies with radically different sales motions use the same opportunity-review screen?\n\nMuch harder to explain.\n\nHistorically, the second question barely mattered because arbitrary variation was prohibitively expensive.\n\nWhen variation gets cheap, sameness becomes a choice that needs a reason.\n\nAnyone old enough to remember serious bespoke enterprise software should be nervous at this point.\n\nWe already tried letting every organization have its own software.\n\nIt produced enormous amounts of archaeology: mystery scripts, custom databases, frozen vendor forks, spreadsheets acting as critical infrastructure, and integrations nobody dared touch.\n\nCustomization gave us local fit and global incoherence.\n\nAI can reproduce that disaster much faster.\n\nThe answer is not to avoid bespoke software.\n\nIt is to stop making the whole stack bespoke.\n\nStewart Brand’s idea of pace layers is useful here. Healthy complex systems contain parts that change at different rates. Fast layers experiment. Slow layers provide continuity.\n\nSoftware is no different.\n\nA dashboard can change tomorrow. A team’s workflow can change next month. The authoritative definition of a customer may need to survive for years. Identity and authority can survive generations of applications.\n\nProblems arise when those layers become fused.\n\nA temporary workflow gets baked into a data model. An org chart leaks into authorization. A UI assumption becomes an API contract. A local integration becomes the only place an important business rule exists.\n\nThen fast change starts dragging slow meaning behind it.\n\nThe architectural rule for mass-customized SaaS is simple:\n\nStandardize the slow layers. Generate the fast layers.\n\nThe point of strong architecture is not to prevent customization.\n\n**It is to make customization cheap without making the system incoherent.**\n\nThe slow layers give the generated software something to push against.\n\nA claims interface can change. The meaning of a claim should not casually change with it.\n\nA team’s workflow can be regenerated next week. The identity model underneath it should not be reinvented because a generator found another representation more convenient.\n\nA temporary reporting application can disappear. The authoritative financial data and audit trail cannot disappear with it.\n\nCheap variation is safe only when something durable constrains it.\n\nThe old bespoke era had another problem: every customization became something you had to maintain.\n\nA customer modified version 4.2. The vendor shipped 4.3. Now somebody had to merge the changes.\n\nOver time, custom software accumulated weight.\n\nGenerative software offers another possibility.\n\nSuppose the durable things are not the generated implementation itself but the customer’s intent, applicable policies, architectural constraints, available capabilities, data contracts, provenance, and evaluations that establish acceptable behavior.\n\nThe implementation can be derived from those artifacts.\n\nThe workflow changes. Regenerate it.\n\nThe platform changes. Regenerate it.\n\nThe company reorganizes. Regenerate it.\n\nThis gives us something the old customization model did not:\n\n**Customization without forks.**\n\nThere is a very large assumption hiding here.\n\nIntent, constraints, provenance, and evaluations have to become durable enough that an implementation can actually be regenerated from them. If they are incomplete, stale, or wrong, regeneration will faithfully produce the wrong software.\n\nThat is the problem I have been exploring in [The Phoenix Architecture and my Regenerative Software work](https://aicoding.leaflet.pub/): if code becomes disposable, the knowledge required to recreate it cannot remain trapped inside the code.\n\nIf we can solve enough of that problem, the economics change dramatically.\n\nA vendor no longer has to maintain ten thousand diverging implementations by hand.\n\nIt maintains a shared substrate plus the durable knowledge necessary to produce ten thousand variations.\n\nThe implementations become replaceable.\n\nThere is an obvious operational objection.\n\nWho supports ten thousand different applications?\n\nWho tests them?\n\nWhat does SOC 2 or HIPAA certification mean if customer A and customer B are running different generated interfaces and workflows?\n\nCustomization without forks solves the source-maintenance problem. It does not automatically solve support, testing, security, or compliance.\n\nIf every variation is an unconstrained snowflake, mass-customized SaaS collapses under its own operational cost.\n\nThat is why the slow layer has to include more than APIs.\n\nIt needs a governed execution environment with common identity and authorization, telemetry, deployment controls, data contracts, security boundaries, policy enforcement, and evaluation frameworks.\n\nA customer’s software can be different without being arbitrary.\n\nCloud platforms already do something analogous one layer lower. Millions of applications can be different because the infrastructure underneath them standardizes enough operational behavior to make that diversity manageable.\n\nThe next generation of SaaS may do the same thing above the infrastructure layer.\n\nDifferent applications.\n\nCommon guarantees.\n\nSupport changes too. The vendor should not need a human support engineer to reverse-engineer every customer’s generated source code. It needs enough provenance, telemetry, constraints, and reproducibility to answer what was generated, why it was generated, what changed, and whether it remains inside the supported envelope.\n\nOtherwise we have merely reinvented consultingware at AI speed.\n\nThis reframes the strategic question for software companies.\n\nWhat are customers actually paying you for?\n\nIf the answer is mostly CRUD screens, generic workflows, dashboards, forms, approval logic, reports, and a configurable database, then the ground is moving.\n\nThose things remain useful, but part of their historical value came from the fact that somebody had to write and maintain them.\n\nIf the answer is a trusted network, authoritative data, regulatory expertise, money movement, a system of record, an ecosystem, accumulated institutional knowledge, auditability, or operational responsibility, then cheap code does not reproduce the important part.\n\nThe visible application can shrink while the substrate becomes more valuable.\n\n[IDC has described](https://www.idc.com/resource-center/blog/agent-supplier-or-featureware-the-choice-every-saas-vendor-faces-now/) one possible version of this future as SaaS applications becoming “featureware,” with agents owning more of the interaction while existing applications remain underneath as governed systems of record and capabilities.\n\nI think the opportunity is more ambitious than accepting demotion behind an agent.\n\nThe best SaaS companies can deliberately become **substrate companies**.\n\nThey own the slow layer.\n\nThey make it safe to generate the fast one.\n\nIf I ran a SaaS company today, I would ask:\n\nIf every customer had a bespoke application tomorrow, what part of our product would they still need to share?\n\nThat question separates the application from the durable business underneath it.\n\nFor Stripe, the answer is obviously not a checkout form.\n\nFor a payroll company, it is not the employee table.\n\nFor a financial information company, it is not a dashboard.\n\nFor some companies, the answer will be substantial.\n\nFor others, it may turn out that most of the product lives in the fast layer.\n\nThat does not mean those companies disappear tomorrow.\n\nIt does mean they should probably be racing to discover what they own underneath the UI before somebody else does.\n\nThe same economics changes “buy before build.”\n\nThat advice made sense when building an internal application meant staffing a software project indefinitely.\n\nBut consider fifty employees losing twenty minutes a day to a workflow that poorly fits them.\n\nThat may not justify six months of custom development.\n\nIt could easily justify a few days of generated development on top of an existing substrate.\n\nThis can produce a renaissance in internal software.\n\nNot giant IT departments rebuilding SAP.\n\nSmall teams maintaining strong shared foundations while producing highly specific tools around them.\n\nTheir advantage is not that they can type code better than a SaaS vendor.\n\nIt is that they know the organization: its language, policies, data, authority structure, exceptions, and history.\n\nThese are exactly the details generalized software has always had to abstract away.\n\nDifference becomes the internal team’s comparative advantage.\n\nThere is a nightmare version of all of this.\n\nEvery team starts generating applications. Each creates another representation of customer identity, invents another permissions model, or makes another convenient copy of important data. Every agent gets whatever access makes the current task easiest.\n\nWithin a year, the company owns a thousand locally sensible applications that disagree about basic reality.\n\nGeneration makes this easier, not harder.\n\nSo someone still has to own the slow layers.\n\nThere needs to be authoritative data, shared domain concepts where common meaning matters, stable capabilities, authority boundaries, protocols, and constraints on what generated software is allowed to do.\n\nThe governance should match the pace.\n\nA team should be able to regenerate its dashboard without an architecture committee.\n\nRedefining who may move company money is different.\n\nIf every change requires central approval, customization dies.\n\nIf nothing requires it, coherence dies.\n\nGood architecture tells us which is which.\n\nThe traditional enterprise decision was made at the application level:\n\nShould we build a CRM or buy one?\n\nBuild payroll or buy it?\n\nBuild a support system or buy one?\n\nThat unit may be too large.\n\nThe better question is:\n\nWhich layers should we buy, which should we share, and which should we generate?\n\nBuy the network.\n\nShare authoritative data.\n\nStandardize identity.\n\nReuse the regulatory engine.\n\nOutsource the operational responsibility you do not want.\n\nGenerate the workflow, interface, reports, and orchestration.\n\nRegenerate the things whose requirements change quickly.\n\nPreserve the things whose meaning needs to remain stable.\n\nA healthcare record should move slowly. The application one clinical team uses around it may move constantly.\n\nAn accounting ledger should move slowly. The CFO’s current reporting experience probably should not.\n\nA customer identity should be durable. The sales workflow surrounding it can be peculiar to one company.\n\nThis is not build versus buy anymore.\n\nIt is build, buy, share, generate, and regenerate, each applied at the right pace.\n\nConfiguration starts with the product.\n\nHere is our application.\n\nHere are the dimensions along which we anticipated you might differ.\n\nTell us which values you want.\n\nGeneration can start somewhere else.\n\nWhat are you trying to accomplish?\n\nWhat data and capabilities exist?\n\nWhat policies constrain them?\n\nWhat does success look like?\n\nGenerate something appropriate.\n\nThat reverses the relationship between software and the organization.\n\nFor decades, organizations increasingly became instances of applications. They mapped themselves into the nouns, workflows, and screens provided by the software they bought.\n\nGenerative systems make another relationship possible:\n\n**The application becomes an instance of the organization.**\n\nThat does not mean every difference is good.\n\nIt means difference no longer has to be rejected merely because it would have required another codebase.\n\nThe history of business software starts to look like three eras.\n\nThe first was bespoke: excellent local fit, terrible economics.\n\nThe second was standardized: packaged software and SaaS gave us extraordinary economies of scale by persuading enormous numbers of organizations to share applications.\n\nThe third may combine both.\n\nShared slow layers. Bespoke fast layers. Centralized operations. Local fit. Stable foundations. Replaceable applications.\n\nThe first SaaS era achieved economies of scale by eliminating variation.\n\nThe next one may achieve economies of scale while restoring it.\n\nThat is why I don’t think SaaS is dead.\n\nCompanies will still buy software as a service. Vendors will still host it. In many cases they may host even more of it.\n\nWhat changes is the default assumption that the visible application must be substantially identical for everyone.\n\nFor the last twenty-five years, the software industry has asked an extraordinarily profitable question:\n\nWhat application can ten thousand companies share?\n\nThe next era asks a different one:\n\nWhat must ten thousand companies share so that everything else can safely be different?\n\nOne service.\n\nTen thousand applications.\n\nSaaS isn’t dead.\n\n**Sameness is.**", "url": "https://wpnews.pro/news/saas-isnt-dead-sameness-is", "canonical_source": "https://aicoding.leaflet.pub/3mtu6c5wsvc2n", "published_at": "2026-08-24 20:45:12+00:00", "updated_at": "2026-08-24 21:12:47.718559+00:00", "lang": "en", "topics": ["ai-agents", "ai-policy", "ai-products"], "entities": ["Gartner", "Klarna", "Salesforce", "SAP", "Workday", "Jira", "ServiceNow", "Oracle"], "alternates": {"html": "https://wpnews.pro/news/saas-isnt-dead-sameness-is", "markdown": "https://wpnews.pro/news/saas-isnt-dead-sameness-is.md", "text": "https://wpnews.pro/news/saas-isnt-dead-sameness-is.txt", "jsonld": "https://wpnews.pro/news/saas-isnt-dead-sameness-is.jsonld"}}