In an earlier post in this series, I had posited that most enterprise AI software is a services business with a subscription attached, and that the decision worth arguing about is own or rent, with build or buy as the distraction. It drew more debate than anything else I have published. I still think it's right but I might have stated it too broadly, and the pushback I got was fair enough to nuance it.
The rule I offered was that renting makes sense when the vendor holds data you structurally cannot obtain. That's true as far as it goes, and it's narrow enough to be argued with conviction on either side. Over the summer I came up with a better version, and it is easier to adopt as a rule of thumb than case by case.
Horizontal software is where renting is straightforwardly correct. Categories like expense management, payroll, HR, procurement, lead generation, the service desk, most enterprise CRM. The process is substantially the same at every company that runs it, because there is no competitive advantage in having an idiosyncratic expense policy and never has been. So the vendor sees the same workflow ten thousand times over. The data pools into something none of its customers could assemble alone, the model gets trained on the aggregate, and other people's exceptions become your product improvements. You are buying the benefit of scale, the scale is real, and the subscription is a fair price for it. I have no argument with any of that, and a company writing its own expense tool in 2026 has made a mistake that has nothing to do with AI.
ERP is the awkward case and worth naming, because it is the first thing most people think of. The finance and record-keeping core behaves like every other category in that list. The manufacturing, order-to-cash and service configuration sitting on top of it does not, which is why ERP implementations are the standard illustration of the problem below rather than an exception to it.
Vertical software is where the same arrangement stops working, and it fails on each condition separately, let me explain how. In vertical software, many flows are heavily custom, because a vertical process carries the history of the business that runs it — the extra approval from a 2019 incident, the field an auditor asked for once during Covid, but stayed after for different reasons. Two companies in the same industry, running the same product, configure it differently and for reasons that are load-bearing in both. The data is scarce and it doesn't pool: there's less of it per customer, it's usually walled off by contract, and the customisation means one customer's exception handling doesn't transfer to the next one anyway. Which leaves the next condition unmet as a consequence of the first two. The product does not get better for you because of work the vendor did for somebody else. What does improve with scale is the vendor's ability to deliver — the second implementation runs at half the cost of the first — and that gain sits on their side of the table.
So in vertical software you pay rent and receive very little of what rent is supposed to buy. That's the state of the argument as of the third post, and it's where I'd have left it if the economics underneath hadn't moved.
The strongest case for renting rather than owning was never really about capability. It was about maintenance. Code rots, dependencies move, the operating system changes underneath you, the person who wrote it leaves, and someone has to keep the thing running for the next decade. A vendor amortises that across every customer it has, which is a genuine efficiency and it drove decades of procurement doctrine. Nobody wants to be the company still maintaining a bespoke system nobody remembers building. Pre-SaaS, these were Notes Databases, Sharepoint sites, custom software written by a local provider with a relationship with the department that commissioned it, etc. These were generally replaced by SaaS offerings, which did take on the burden of maintenance - so the 'rent' model worked out in practice for buyers.
That premise has weakened considerably faster than the doctrine resting on it, particularly in the agentic software era. Documenting and writing code has become cheap, and keeping it running has become cheap along with it, for the same reasons and to roughly the same degree. What has not become cheap — what has become the most expensive part — is keeping the system's context current. The encoded exceptions, the process logic, the evaluation sets, the recorded reasons a particular step exists at all. That work never stops, because the business doesn't. An acquisition arrives with a different chart of accounts. A new product line has warranty terms that didn't exist before. A single client negotiated a policy exception two years ago that wasn't encoded during implementation and has suddenly become a hot-button topic with the audit committee. A regulation changes what has to be evidenced. A large counterparty starts invoicing in a format that breaks an assumption made three years ago. Each one requires the judgement encoded in the system to be found, revisited and refreshed, and none of it is a coding problem, although it lives in code.
That inverts who holds the advantage. On code maintenance the vendor was genuinely better placed, and the argument for handing it over was sound. On context maintenance the customer holds every advantage there is, and the vendor is structurally the worst-positioned party in the room: their team learned the context once, during implementation, at the customer's expense, and then moved to the next account. The vendor wouldn't want to own this, shouldn't own but will end up owning it under the current model.
So the rule I'd offer in place of the one from the third post is short. Rent the horizontal, where scale genuinely accrues to you. Own the vertical, where it never did. And when a vertical vendor makes the maintenance argument — that you don't want to be maintaining this yourself — that's the moment to work out together which maintenance is being described. If it's keeping the code alive, that got cheap, and the saving belongs somewhere in the negotiation. If it's keeping the context current, then what's being described is work that only your own people can do, and the subscription is buying you the party with the least access to it.
That's the twelfth pattern.