There's a pattern I've watched play out across the insurance industry so many times that I could set my watch to it. A carrier identifies a problem: claims processing, beneficiary communications, workflow automation, take your pick. Their leadership team convenes. Someone in the room says, "We have a tech team. Why don't we just build this ourselves?"
And the room nods.
I get it. I really do. There's something deeply satisfying about building your own solution. It feels strategic. It feels like ownership. It feels like control. But here's what I've learned after years of working with carriers of all shapes and sizes: the build decision almost always looks brilliant on day one and disastrous by year three.
Let me be clear — carriers can build technology. Their teams are talented. Their developers are capable. And when that new internal platform finally goes live, the energy in the room is palpable. The demos look clean. The leadership team is proud. Someone puts together a slide deck celebrating the achievement.
This is what I call the Shiny Object Phase. The thing is new, it's yours, and it works. At least for right now.
But then Monday morning arrives. And Tuesday. And before long, the real question isn't whether they could build it. The real question surfaces: Can they sustain it?
I say this often, and I mean it every time: any insurance company can build a technology solution. Given enough time, budget, and talent, they can absolutely get something built. I've never questioned that.
But that's the wrong question.
But the question that almost never gets asked in that initial meeting is: "Should we build this?" And when you honestly evaluate everything that comes after the build, for most carriers, the answer is probably not.
You're an insurance carrier at your core, not a technology company. The moment you decide to build and own a technology platform, you've also made a long-term commitment to operating and improving that platform over time. And eventually, that tension shows up — in your budget, in your talent, and in the challenge of maintaining a product that keeps pace with the market.
Here's where the wheels start coming off, and it happens with remarkable consistency.
The cost-benefit analysis that justified the build decision almost universally accounts for one thing: the cost to build for the standard cases. What it rarely accounts for — and this is the part that keeps insurance CTOs up at night — are all the costs that come after the ribbon cutting.
We're talking about maintaining the system. Hosting it. Upgrading it as infrastructure evolves. Making changes every time a regulation shifts, a workflow changes, or a user need emerges. And perhaps most underestimated of all: the ongoing cost of the people whose entire job becomes watching that system, babysitting it, keeping it breathing.
What teams rarely budget for is the last 20%. The first 80% of a platform usually gets built. It’s the edge cases, exceptions, integrations, and long-tail maintenance work that quietly compounds over time.
As BreAnna McGee of Wellabe noted in Benekiva’s recent 2026 Blueprint for Modern, Compassionate, and Connected Claims:
“You may automate 80% of the claims, but you end up with even more system and knowledge sprawl.”
Jim Girard, VP of Engineering at Benekiva, framed it even more bluntly: “The 20% requires twice as much time and twice as much money.”
Robert Mattioda, CEO of The Life and Annuities Group, put it bluntly: carriers often spend hundreds of thousands of dollars solving narrow edge cases internally when purpose-built platforms already handle the core workflows at scale.
Those costs are not small. And they compound. Year over year, what looked like a one-time capital investment quietly transforms into a permanent operational expense with no end in sight — and no vendor to call when something breaks at 2 a.m.
A few years pass. The team that built the original system has largely turned over. The documentation is incomplete, or optimistically written, or simply missing. The newer developers look at the codebase the way someone looks at a storage unit they inherited — they know there's something valuable in there, but they're not entirely sure what, and nobody wants to be the one to dig through it.
This is technical debt, and the insurance industry is carrying a staggering amount of it.
What makes it particularly painful is that it's debt nobody wants to touch. You can't retire it easily. You can't just delete it. Every new feature request gets filtered through the spaghetti of decisions made three years ago by people who no longer work there. Development slows. Costs rise. The people who championed the original build are usually long gone, and the people left holding the bag are frustrated, underfunded, and quietly looking at vendor solutions, the same ones that were passed over in favor of building internally.
Here is the honest truth that I think the industry needs to sit with: insurance carriers are not technology companies.
That's not a criticism. It's a clarity statement. Carriers are in the business of managing risk, serving policyholders, and paying claims with speed and accuracy. That's what they're built for. That's where their expertise lives. That's what their customers need them to be exceptional at.
Technology companies, on the other hand, are built for exactly the opposite skill set. They wake up every morning thinking about product roadmaps, infrastructure scalability, user experience iteration, and competitive feature development. That's their entire reason for existing. It's all they do.
When a carrier decides to build and maintain a complex technology platform, they're essentially asking their organization to become two fundamentally different businesses at once. And in my experience, one of them always suffers.
When carriers partner with purpose-built technology companies, they're not just buying a product. They're buying a team of people whose entire professional identity is wrapped up in making that product better every single day. They're buying a roadmap that evolves with the industry. They're buying upgrades that happen without a capital budget request. They're buying support that exists because the vendor's survival depends on the carrier's success.
More importantly, they're buying back their own focus. When your technology is handled, your leadership team can go back to doing what insurance companies do best: serving customers, managing risk, and growing the business.
That's not a small thing. That's the whole game.
If you're sitting in a room right now, evaluating whether to build or buy a new platform, I'd ask you to do one thing before you make that decision: build a complete cost-benefit analysis.
Not just the cost to build. The cost to host. The cost to maintain. The cost to upgrade. The cost to make changes. The cost of the people who will spend their careers keeping it running. The cost of the technical debt you'll inherit in five years. The cost of the opportunity you'll miss because your best developers are maintaining a legacy system instead of driving innovation.
Do that math honestly, and the build decision looks very different.
The shiny object is always appealing in the moment. But the carriers who win long-term are the ones who stay focused on what they do best — and trust the right partners to do the rest. Can you build it? Almost certainly. But should you? That's the question worth asking. And more often than not, the honest answer points you in a very different direction.
Brent Williams is the Founder and CEO of Benekiva, a cloud-native insurtech platform purpose-built for claims processing automation. Benekiva serves insurance carriers with a focus on speed, automation, and human-centered design.
