I want to be upfront about something before I make this argument, because the honest version of it cuts towards my own commercial interests and I'd rather say so now than have you work it out somewhere around paragraph nine.
Here's the pattern. A company evaluates an AI application. The vendor demos well. Procurement runs the usual playbook, because the thing looks like software: seat count, annual commitment, security review, three year term, somewhere between 150k and 400k a year depending on scale and how well the negotiation went.
Then delivery starts and the shape of it changes completely. Six weeks of workshops. Process mapping. The vendor's team learning how your exceptions work, because your exceptions are not the ones in the demo. Prompts rewritten against your document formats. Integrations into three systems nobody mentioned during the sales cycle. A pilot group, then retraining after the pilot group points out it doesn't handle third party cases. Nine months later it works, roughly, on the part of the process it was scoped for.
Now ask what you actually bought. The intelligence came from OpenAI or Anthropic or Google, and you could have called those APIs yourself for a fraction of the cost. The interface is a handful of screens. The value, all of it, is in that middle paragraph: the mapping of your process, your exceptions and your judgement, encoded. That was implementation work. You paid for it once during delivery, and now you're paying for it again every year, forever, for permission to keep using the result. That isn't a software product. It's a consulting engagement wearing a SaaS pricing model, and it is currently the most profitable business in enterprise technology.
The trap in how this gets discussed is the build versus buy question, which is a distraction, and conveniently it's the axis every vendor would prefer you argue on, because it lets "buy" and "rent" be treated as the same word. They aren't, and the difference is the whole thing.
So the rule I'd apply instead has three parts. Build or buy, as long as you own it. Owning means the code, the configuration, the process logic and the accumulated exception handling sit in your repository on your infrastructure and keep working if the supplier disappears tomorrow. A perpetual licence qualifies. An on premise deployment qualifies. Anything a competent internal team or a different firm could pick up qualifies. A hosted subscription where cancelling makes the capability evaporate does not, whatever the contract calls itself.
Second, when the capability is undifferentiated, buy it, and still own it. There's no virtue in writing your own document parser and no prize for having done so. There is a real problem with renting one on terms that mean nine years of accumulated institutional exception handling ends up living inside somebody else's product.
Third, renting only makes sense when the vendor has data you can never get, and that data makes the service materially better than anything you could build. The distinction is data, structurally unavailable to you, not model quality — and the word structurally is doing the work in that sentence.
That third rule sounds narrow because it is, but test it against the cases where renting is obviously the right answer and it holds up every time. A credit bureau has the file and you cannot assemble it. A fraud consortium sees transactions across two hundred institutions where you only see your own. A security vendor watches telemetry from every customer it has, which is how it knows about an attack an hour before it reaches you. Westlaw licensed the case law and no amount of money buys you an equivalent corpus. Look at what's being rented in each of those and it's the dataset, every time. The model is just a delivery mechanism for data you have no route to, and that's a fair trade you should pay for happily.
Then apply the same test to whatever AI application is sitting in your procurement queue right now, by asking the vendor one question. Name the data you have that I structurally cannot obtain, and explain why I can't get it. If the answer is a named corpus with a real reason attached, you're looking at a legitimate rental and the rest is price negotiation. If the answer is some variation on "our models are fine tuned" or "we've learned a lot from our customers", then what they have is a head start assembled out of other people's processes, and what they're selling you is a subscription to your own.
Very few AI applications on the market today survive that question. I've asked it in three procurement processes so far and got a straight answer once. [ROY: replace with your real count if it's different, this number carries the section.]
There's one legitimate reason to rent that doesn't fit the data rule, and a good CFO will raise it, which is that sometimes you're buying indemnity rather than software. A vendor certifies the output and carries the liability, in regulated reporting or clinical coding or similar. That's a real thing to buy and I've got no quarrel with it. But it's insurance, so price it as insurance: ask what the cap is, what's excluded, and what has actually been paid out to date. Most vendors selling comfort in this category have never quantified the policy, which means you're paying a premium against an obligation nobody has written down.
Which brings me back to the disclosure. Raining Code makes money from this argument. We come in, build the thing, and stay on to maintain it, and that is a recurring line on somebody's budget. I'm not going to pretend otherwise, and if the argument only worked when nobody looked at my incentives it wouldn't be worth publishing.
What I'd ask you to hold me to is the distinction the whole post rests on. Paying somebody to maintain an asset you own is what every company already does with its ERP, its plant and its data warehouse, and nobody has ever called that a scam. Paying for continued permission to use something built out of your own process is a different transaction wearing similar clothes. There's a test for telling which one you're in, and you can run it on us or on anybody else, at any point, not just at the start: could another competent firm take this over in thirty days using only what's in your repository? A vendor product is engineered so the answer is permanently no, and that's a rational business model, just not one you should confuse with buying software. My claim is that for this kind of work the answer should be yes on day one and still yes in year four, and that you should go and check rather than take anyone's word for it, mine included.
That's the third pattern.