There is no consensus answer to the build-versus-buy question in US insurance technology. The firms getting it right are not converging on a single approach. They are each arriving at a position that reflects their size, their competitive differentiation, and their view of where their data goes when it leaves the building.
That last point is the one that tends to get glossed over in vendor conversations.
Ryan Deeds, head of AI and enablement at ALKEME, names it directly. "I freak out when we want to buy stuff and give away data to them. It's easier for us to integrate some of this stuff directly into our workflows and use the two or three features specifically than the entire solution."
Kristen Skender, chief growth officer at Jimcor Agencies, frames the same concern from a competitive angle. "We have to understand what is happening to our data, who's gaining access, what might they use it for, and how does it impact our competitive edge? So I think to the extent that we can protect that and utilize building our own technology, we're adding components in terms of what we are considering buying. It's not necessarily an entire bot solution, so that we keep our competitive edge."
The data sovereignty concern is not abstract. When an agency's client data, policy history, and producer relationships flow into a vendor's platform, that vendor is building a dataset that may inform their product development, their pricing, and potentially their own competitive offerings. The question of what a vendor does with the data they receive belongs in every vendor evaluation, and it is rarely asked with sufficient rigor.
Kate Grasman, chief information officer at Heffernan Group, takes a fundamentally different position - and argues it just as clearly.
"I'm probably more of a buy CIO or partner CIO. I know how much it takes to innovate and maintain systems, and I'm really just interested in getting the best talent out there. We're an insurance company. We're not a tech company. So I look to partner with people to innovate faster and learn from that."
Her framing of competitive differentiation is direct. "A policy check or an endorsement isn't really a competitive advantage. So, even if I'm partnered with someone to build that, that's just table stakes at this point."
That argument - that the processes most agencies are debating whether to build or buy are not the ones that differentiate them - is a direct counterpoint to the data sovereignty concern. If the capability being purchased is genuinely commoditized, the competitive risk of sharing that data is low. The risk of building and maintaining it in-house, and falling behind a vendor investing in it continuously, may be higher.
Jennifer Kessel, chief operating officer at USG Insurance Services, has spent 25 years building rather than buying, and she makes the case for that discipline on grounds that go beyond competitive advantage.
"Built our technology over the last 25 years, and we continue to do so,” she said. “We rarely ever buy technology. For us, it has really made us be strategic about what we're implementing, because when you're buying and you have the money, you can buy a bunch of products at a time. But it's really forced us to sit down and say, 'What does our team need? What's going to add more value? What's producing ROI to the bottom line? Where is it most needed?' And that's what we're going to go build."
The constraint she identifies - that building forces prioritization in a way that buying does not - is a genuine organizational benefit that gets less attention than the technical arguments. When the cost of acquiring a capability requires internal engineering investment, the business case has to be made clearly before the work begins. When capability can be purchased with a subscription, that discipline erodes.
Her reasoning for avoiding vendor dependency is equally clear. "We've never wanted to rely on a technology partner to work on the next version of their platform. We want to be working on the next version of our platform and drive where it's going."
The most pragmatic position in the roundtable came from Deeds and Skender, who independently described a middle path: buying components rather than full solutions.
"It's pieces of a larger software platform. It's not necessarily an entire bot solution so that we keep our competitive edge," Skender said. Deeds agreed. "It's easier for us to integrate some of this stuff directly into our workflows and use the two or three features specifically than the entire solution."
That components-first approach threads between the build and buy extremes. It captures vendor-developed innovation in specific workflow areas without handing over the full data relationship or accepting platform lock-in. It also requires a clearer upfront definition of which workflows actually benefit from vendor capability versus which ones are core enough to build and own.
None of the four approaches is obviously wrong. What is wrong is choosing a strategy by default - buying everything because procurement is easy, or building everything because it has always been done that way - without examining what each decision does to the firm's data, its competitive position, and its ability to change course when the technology landscape shifts.
