Last week I spent an hour on the phone with an insurance company. They want to rebuild their website and their mobile app. Claims submission, policy servicing, document upload, and a handoff to a human agent for the moment the flow breaks, and in claims the flow breaks most of the time. Real project, real users.
Ten minutes in, he asked to see my software.
Not a reference architecture. Not a case study. A product demo. He wanted screens, an admin panel, license tiers and the roadmap for next year.
I told him there isn’t one, and we spent the remaining fifty minutes not understanding each other.
The gap was never technical. He knew what AI does. He did not know what he was supposed to sign.
What he thought he was buying
He wasn’t being difficult. He was doing his job the way his company has always done it. Different thing, and much harder to argue with.
The shopping list in his head looked like this:
- A software that builds the website
- A software that manages the content
- A software that handles the claims workflow
- A software that ties the three together
Four products, probably three vendors, and a set of roadmaps that belong to somebody else.
That is the model he knows. More to the point, it is the model his procurement department is built around, and he does not get to change that on a Tuesday afternoon because a supplier told him the world moved.
At a glance: two ways of buying the same outcome
| Buying a license | Buying a build |
|---|---|
| Compare feature matrices | Describe the outcome you want |
| Named product, named version | Nothing to name until it exists |
| Three references, same deployment | Nobody runs the same thing as you |
| Vendor owns the roadmap | You own the roadmap |
| Priced per seat, per year | Priced by what it does, per run |
One of those columns is a comparison exercise. The other one asks you to say what you want before anyone has built it. Completely different skill, and a much less comfortable one.
The sentence that ended the call
So I made him what I thought was a generous offer. Send me your specifications, and rough is fine. A Word document with bullets. A screenshot of the current claims page with arrows drawn on it in red. I have worked from worse.
Give me that and I come back with something he can click, not a deck.
His answer has stayed with me all week.
I don’t know what I want. I want you to arrive with a software.
— The client, on the call, August 2026. I am not naming him or the company. I have heard close variants of that sentence from other buyers this year.
Price never came up, not once, which should have told me something earlier than it did. The problem was that an offer arriving in any shape other than a product is an offer his organization has no way to approve.
This is a procurement problem, not an AI problem
Most of what I read about slow AI adoption in traditional industries blames the technology. Models hallucinate. Compliance blocks everything. The data is a mess, and to be fair the data usually is a mess.
None of that came up in sixty minutes. Not once.
What blocked the conversation was purely commercial. He knows how to buy a license. He has no process for buying build capacity, and no vocabulary for it either.
Those are two different organizational muscles. Buying a license means running a comparison between things that already exist, which most companies have spent fifteen years getting very good at. Buying a build means describing an outcome and then trusting somebody to produce it. That second muscle atrophied while everyone was busy perfecting the first, and nobody noticed because until recently there was no reason to use it.
When comparison is your only buying skill, a supplier who refuses to be compared reads as a risk rather than an opportunity, and the buyer is not wrong to read it that way given what he is measured on.
His caution is earned
It’d be easy to write this client up as a dinosaur, and I want to avoid that, because he isn’t one.
Packaged software gives you things that genuinely matter. Somebody else carries the maintenance and patches the security holes at two in the morning without asking you. Other customers run the same code, which means most of the bugs get found by people who are not you. And when it goes wrong there is a contract to point at, with a name on it.
Custom software has a long and well documented history of going badly. Anyone who has spent twenty years in enterprise IT has watched a bespoke system turn into an unmaintainable liability that outlived three CTOs. Somebody paid for that lesson, usually with their job, and the caution he inherited from it is the residue of a real event rather than a personality trait.
So the question isn’t whether that caution was justified. It was. The question is whether it still points where it used to point.
The cost of building fell, and that is the whole story
The cost of building fell, and most buyers have not absorbed how far. Nobody sent them a memo. The vendors they talk to have no reason to send one, and the trade press covers the models rather than the invoice.
I wrote in this collection, in the piece on the job apocalypse, about a weekend where I shipped two working agents alone that would have taken a small team a few weeks eighteen months earlier. That was not a stunt. It is now the normal shape of the work, and it repeats across every function we have built for.
When building is cheap, buying a rigid product in order to avoid building is no longer the safe option. It is just the familiar one.
That changes the arithmetic for a large category of applications. Not all of them. A core policy administration system is not on that list and I would not pretend otherwise. But a claims portal is mostly intake, document capture, status, a rules pass, an exception queue and a handoff, and every one of those is a pattern we have already shipped somewhere else. So is most of what his four products were supposed to cover.
What did not get cheaper
Before that reads like a sales pitch, and I can hear that it does, the other half.
I’m not going to oversell this, least of all in insurance.
Regulated industries still have constraints that no model erases:
- Data residency and privacy rules do not relax because the code arrived faster
- Auditability of a claims decision is a legal requirement, not a feature
- Somebody still owns the system in year three, after the person who built it has moved on
- Integration with a thirty year old policy system is where these projects actually die, and generated code does not fix a bad interface
The speed is real. The governance work didn’t shrink with it. If anything it matters more now, because the same number of reviewers are looking at several times as much output per week. Anyone telling an insurer otherwise is selling them a failure with a short delivery date.
The tender document is where the deal dies
The most concrete symptom of all this is the paperwork.
A standard request for proposal on a project like his asks four questions I cannot answer honestly.
The four questions, and the honest answer to each
| What the tender asks | The honest answer |
|---|---|
| Name and version of the platform | There is no platform name |
| License cost per user, per year | Seats cost nothing. Runs are metered |
| Three live references, same build | Nothing I build is identical to yours |
| Product roadmap, next 24 months | The roadmap is yours, not mine |
The second column is the honest one and it reads terribly. Take the pricing line. What I mean by it is that giving an account to forty people costs the same as giving one to four, and the invoice moves with what the system actually runs. For a buyer whose entire cost model is headcount multiplied by an annual seat price, that is not a discount, it is a category he has no cell for. Read the rest of the column through a procurement officer’s eyes and every answer looks evasive. A process designed to filter out vagueness ends up filtering out the better offer, and the buyer never finds out that is what happened, because the supplier who could not fill the form simply stops replying.
None of that is a failure of the buyer’s intelligence. The form is doing exactly what it was built to do, and doing it well, in a market that stopped resembling the one it was written for.
What I changed in how I sell
That is all diagnosis, and diagnosis is cheap. Here is what changing actually cost me.
I stopped explaining. Explaining doesn’t work on this buyer. He isn’t confused about AI, he reads the same coverage everybody reads. He’s confused about what he is supposed to put in front of his own approval committee.
So I changed the order of operations:
- I do not pitch capability anymore, I bring an artifact
- Before the second meeting I build a rough version of their thing, with their logo and their actual claims flow in it
- I put it in front of them and let them click it
- Then I ask what is wrong with it
Complaints turn out to be specifications, which I did not expect. A buyer who can’t write a spec can always tell you what’s wrong with something on his screen, and he’ll do it in detail, unprompted, in about ninety seconds. That’s the fastest route I know from “I don’t know what I want” to a scope somebody will sign.
It costs me a few days per prospect, and I lose some of those days on deals that were never going to close. I still think it beats the abstract conversation, which costs the same few days and ends with a follow-up call.
Where I could be wrong
I sell this. That’s a reason to discount my reading, not to accept it.
The obvious counter is that his instinct protects him from me. If the build goes wrong, he has no vendor to sue and no other customer running the same code to compare notes with. My answer is a written scope, an approval gate in front of anything that publishes or spends, and code he keeps at the end. I believe those answers. They are also answers I designed, which is not the same as answers he tested, and sitting in his chair I would probably find them thin.
There is also a version where packaged software absorbs all of this and the build advantage closes. The large platforms are shipping the same agent patterns into their products right now. If they get there, the honest conclusion is that he was right to wait and I was early. That has happened to me before. It will probably happen again.
Something to do on Monday
Three things, and they work whichever side of the table you sit on. I have started doing the third one myself, which is how I know it is harder than it sounds.
Open the last software tender you ran and count how many questions assume the answer already exists as a product. That number is your filter, and it is probably higher than you would guess.
Ask a supplier for a working prototype before you ask for a proposal. Pay for it if you have to. A few days of somebody’s build time costs less than a selection process that picks the wrong thing for eighteen months.
Write down what you actually need the thing to do, in plain language, badly. The bad version is worth more than the polished requirements document, because it is honest about what you do not know yet.
Three things I would defend
First, the vocabulary. The adoption bottleneck in mid-market enterprises right now isn’t model quality. It’s that buyers only have words for licenses.
The direction. Once a company finds out it can commission a build for what a license renewal costs, it doesn’t go back to the license. That is from our own accounts rather than from a survey, so treat it as a pattern I keep seeing and not as a law.
And the cost of waiting. The buyer who holds out until this arrives as something he can purchase off a page pays for the waiting years, then pays again for the product when it shows up.
Stop asking for the demo. Ask for the prototype.
He wanted me to arrive with a software. What I can arrive with is one function of his claims flow, running on his own data, inside the first week, because that is what onboarding is scoped to do and it runs the same way for every account. It is a smaller promise than the one he was asking for, and a much easier one for him to check before he commits to anything.
Open an account and run one module on one brand, or book a demo and see the platform working on your own numbers rather than on a demo tenant.
Written at the end of August 2026, after a call that did not go well. I will revisit this in six months and mark up whatever I got wrong, the same way I did with the piece on the job apocalypse. If you want the follow up, it goes out to my newsletter list.
