One of my takeaways from ITC Vegas this fall was that a lot of vendors are playing defense. A lot of carriers are looking at what AI can do now and asking some version of the same question: Hold on a minute, the world changed, so should we just build everything ourselves?
It's a fair question. The barriers to building have come down a lot in the last year, and the benefits of owning your own technology are real. When a convincing demo takes a couple of engineers instead of a sales cycle, the old reasons to buy start to look pretty thin.
I suppose I'm not the most neutral person to ask. I've spent the last decade building and running Clearcover, an AI-native carrier, and now Dearborn Labs, an AI-native software development firm built specifically for insurance; if anyone was going to tell you to build everything, it would probably be me. But when people ask me whether to buy or build, my answer is...yes. We have components of our system that we bought and didn't build, and we're fine with that. We build more than we buy, though, and more every day.
Is "yes" a dodge? Maybe a little. Mostly it's that buy vs. build was never one decision. Every carrier already runs a mix of both, workflow by workflow. And even the build half of my answer comes with an asterisk.
Where should the line sit?
The choices sit along a spectrum, made one workflow at a time, and lately the mix has been shifting toward build. That makes sense to me, and I'd expect it to keep shifting for as long as building keeps getting cheaper.
Buy what's already solved well. If a problem looks roughly the same at every carrier, and someone has spent years getting good at it, there isn't much to gain from building your own version, and the time and money are better spent elsewhere. But that list gets shorter every month.
Build the workflows where being different is the point, like how you triage a new claim or decide which risks to write. Buying those means working the same way as everyone else who bought the same thing, which probably isn't what you were going for.
Where exactly that line falls depends a lot on the carrier and its lines of business, which is why a single company-wide decision on buy vs. build usually ends up wrong somewhere.
The asterisk
What qualifies as building, because you can put a demo together, is usually the smallest portion of the work. AI can change how a claim moves and which decisions get made without a person ever opening the file, but the systems underneath that workflow rarely change, or at least they rarely change quickly. Not everybody is doing a rip-and-replace of their whole company to launch a new AI workflow. A new claims-intake workflow still has to post to your core system and set reserves the way your actuaries expect, and an underwriting workbench still has to read from policy admin and write its decisions back. None of that shows up in a demo.
The interface is mostly a solved problem now, and that's good news. The hard part is the wiring underneath it. Most of the AI conversations I have with carriers wind up being about traditional software engineering. That's the work of fitting whatever the AI application or agent is into the rest of the company, so the systems supporting a reinvented workflow still work properly.
And the wiring is only half of the asterisk.
The other half is running the thing in production until people actually work that way. Most implementation projects are scoped to end at go-live, which is roughly where this half starts. At Clearcover, adoption of the AI tools across our claims team is 92%+. A number like that gets earned after go-live, inside real claims, over however long it takes for the new way of working to become just how the job gets done.
You might reasonably ask whether all of this is an argument for buying something that comes already integrated. For the work that's solved well, it is. But a bought workflow is the vendor's workflow, designed to fit as many carriers as possible, and in the workflows you'd want to run differently from everyone else, that's exactly the problem.
Build realistically.
Before you build a new workflow, ask three questions of it:
- Foundation — Was this workflow designed around constraints that no longer exist?
- Fit — Can it work with the systems you already have, without a rip and replace?
- Engineering — Do your engineers own the integration layer today, and can you test, govern and audit what runs on it?
The first is about not building on top of a bad foundation. A lot of insurance workflows were shaped by limits that made sense at the time, like a handoff that existed because two systems couldn't talk to each other, or a sampling audit that existed because nobody could read every file. If you automate that workflow as it stands, what you get is the old process running a little faster, and you've spent real money to keep a constraint you no longer have.
The second one is more encouraging. You don't have to fully rip out your systems to improve a workflow, so long as you have the software engineering chops to fit the new workflow into the systems you have.
The third is the one I'd push on hardest, mostly because a demo is very good at hiding it. If the answer is no, I'd want to know that before the demo goes in front of the Board rather than after.
If you're asking me whether to buy or build, I'd say build more than you used to. Just go in knowing that the demo is the easy part, and that the wiring, plus the long stretch of running it until people actually work that way, is the job. So where does your line sit this year, and who's doing the wiring?
