In March 2023, I published an article called “Why Insurers Shouldn’t Attempt to Build Their Own Software.”
The title did not leave much room for discussion.
I’d leave more room today.
I still worry about insurers underestimating the work that follows a successful demonstration. But “insurance companies shouldn’t build software” is too broad a conclusion. An insurer’s underwriting judgment, portfolio, or operating constraints may call for something available products cannot deliver.
AI makes that possibility more interesting. It also makes the illusion of completion more convincing.
Buying remains my starting point for shared capabilities when a product proves its fit and lifecycle value. I would build selectively where proprietary logic or a distinctive workflow creates an advantage available products cannot deliver.
A dinner party is not a restaurant
A demonstration is a little like cooking one excellent meal for friends.
Everyone likes it. Someone says you should open a restaurant.
Then you discover that a restaurant also needs purchasing, food safety, staffing, substitutions, and a plan for the evening the freezer stops working.
The meal was real. So is the rest of the business.
The dangerous demonstration is not the one that fails. It is the one that succeeds so convincingly that the room mistakes feasibility for readiness.
A demo answers, “Can this work once?” The business case must answer, “Can it keep working—with awkward files, changing rules, absent specialists, security reviews, and Monday-morning support?”
What I would build
If a capability expresses a genuine underwriting advantage, I would take the case for building seriously.
That might be a proprietary appetite rule, a portfolio-allocation method, or a workflow that fits an unusual delegated-authority arrangement. It might also be a small internal tool with a deliberately limited role and a straightforward fallback.
The important word is “deliberately.” A tool that helps someone investigate a submission is different from a tool whose output can flow into a binding decision without further review.
I would ask an internal sponsor to name three things before approving the build:
- The decision or task it improves, and why the available alternatives do not fit.
- The people who will maintain it after the original enthusiasm wears off.
- The boundary beyond which it must stop, ask, or hand over.
“We can build it” is a feasibility statement. “We should own it” is an operating decision.
What I would buy
For a shared capability, I would start with the available products. The case for buying rests on fit, credible support, and better lifecycle value than the internal alternative.
But the vendor has to earn that conclusion.
A polished interface is not evidence that the awkward files work. A subscription is not proof that integration will be easy. And a contract does not automatically make the customer’s business rules somebody else’s responsibility.
I build insurance software for a living. That gives me a commercial interest in this debate, not an exemption from it. Wizard should face the same questions as an internal team.
If the product fails a representative evaluation, “but we bought it” is not a defense.
The sensible answer may be a boundary, not a winner
An insurer does not have to choose between building everything and outsourcing its judgment.
It can buy a component, build the connective workflow, and retain ownership of the decisions that make it distinctive.
That arrangement works only if the seams are explicit. Who maintains the interface? What happens when the supplier changes its output? Which version produced this result? Who investigates a disagreement between two systems?
Five useful tools can still create an unusable process if the underwriter becomes the integration layer.
The hidden cost is not just another license or API call. It is the person re-entering a value, reconciling two answers, or searching a conversation for the assumption that nobody wrote down anywhere else.
The SOV test I would put in both pilots
Consider a fictional record: “Renovated in 2024.”
Was that a new roof, new wiring, or reception-area wallpaper?
If a workflow turns that statement into “roof updated: 2024,” it has not merely cleaned the data. It has introduced a more specific claim than the source supports.
Now challenge the result. Ask why the field was mapped that way. Supply a correction. Send a revised file. Ask a second reviewer to reconstruct what happened.
Run those steps through the internal build and the vendor product using the same approved test material.
Then compare:
- Can the reviewer see the source and the reason for a material transformation?
- Are unresolved questions kept visible rather than converted into plausible answers?
- Can a correction survive the next revision without being silently overwritten?
- Can another person operate the workflow and explain the handoff?
- How much review and correction effort remains before the output is usable?
Decide what evidence would count as a pass before the demonstration. Otherwise, it is remarkably easy to redesign the test around whichever option the room already likes.
Chat history is not an operating manual
There is a second trap in AI-assisted building: the useful explanation can stay in the conversation while the code moves into production.
A prompt contains an exception. A chat explains a mapping choice. Another conversation adds a workaround. The application runs, but nobody has a complete account of the rules it is applying.
Treat important decisions as maintained project records: assumptions, tests, dependencies, known limitations, and who may change them. A colleague should not need the original builder’s memory to operate the tool responsibly.
Check privacy with the same care: public sharing, training use, retention, and third-party access are separate questions. OpenAI states that it does not train on business-product and API data by default, but that commitment does not describe every AI tool or connected service. Check the actual settings, terms, and data flow before sending client information. “Not used for training” is not the same as “not retained.”
“Can you just check this?”
There is another cost that deserves its own line in the business case. Anyone who has been the underwriting representative on an internal technology project may recognize how it starts.
“Could you send us a few sample SOVs?”
Then: “Can you check whether these results look right?”
Then: “We’ve fixed the issue you found. Could you run those files through again?”
Soon, an underwriter is comparing spreadsheets cell by cell, a CAT analyst is explaining why the totals do not reconcile, and someone in operations is documenting exceptions between their regular deadlines. The next release arrives, and the checking starts again.
Each request sounds reasonable. Together, they become a second job.
The underwriting queue has not shrunk. The broker still wants an answer. And the people the software was supposed to free up have become its unofficial QA team.
Business input is essential. Underwriters should help define what a correct result means and confirm that a workflow serves the business. But an open-ended obligation to find defects, explain them, and retest every fix needs an owner, a time budget, and a place in the project’s cost.
Otherwise, the build can appear inexpensive because part of its development bill is being paid out of underwriting, CAT, and operations capacity. Those salaries may already be in the budget. Those hours are still being taken from something else.
A vendor can impose the same burden, and should be challenged when it does. Ask both options: how much expert time is needed to get this working, how much will it keep consuming, and who owns testing after the pilot?
“We used existing resources” does not mean the resources were free.
Compare the next two years, not just the first two weeks
AI can reduce development effort on both sides. Vendors also spread development, improvement, security, and support costs across many customers. That scale advantage predates AI; AI may strengthen it, but lower prices and better value still have to be demonstrated.
Where a shared capability has proved its fit, an all-in annual cost below one fully loaded employee gives buying a strong starting case. It is a benchmark, not a verdict. Internal delivery needs several functions, which may require fractions of several people’s time; buying still needs internal oversight. Cost the actual capacity each option will consume.
The arithmetic should be symmetrical. The internal estimate should include maintenance, testing, infrastructure, support, security review, and the opportunity cost of the team doing the work—including the business specialists borrowed to validate it. The vendor estimate should include implementation, configuration, integration, internal review, supplier dependency, and the cost of leaving.
Compare both options over the same two-year period, using their full costs of ownership. Use the same definition of “usable output,” and measure elapsed turnaround and human effort separately. A fast first output can still leave an underwriter with a long afternoon.
AI may make the prototype cheaper. It does not make the team behind a dependable production system disappear.
Neither side gets to compare its best-case demonstration against the other side's entire operating budget.
The advice I would give now
Defer the project if nobody can explain the operating responsibility, however impressive the demonstration looks.
My 2023 title asked insurers to choose a side. Today I would ask them to choose which responsibilities they intend to own, then decide how best to deliver them.
“We built it over the weekend” is impressive.
“Who owns it on Monday?” is the question that determines whether you built a demonstration or a capability.