I have had some version of this conversation hundreds of times.
A carrier is looking at a technology gap, maybe their claims or workflows or some piece held together by spreadsheets and institutional knowledge for far too long. Someone in the room says, “Can’t we just build this ourselves?”
I understand why that question comes up. Most carriers have smart people and best-in-class IT teams. They have people who understand their business better than any outside vendor ever will. On the surface, building can sound reasonable, but it’s asking the wrong question.
The question is not whether you can build it. With enough time, enough money, and enough talented people, you can build just about anything. The better question is whether you should. And even more than that, whether you want to own everything that comes after.
The first version of a build decision often feels perfectly reasonable. The business case works, a wireframe can be built quickly, and everyone is excited at the idea of owning the roadmap. It can feel like everyone is working together to solve a problem instead of waiting on an external company or a different team to solve it.
There is pride in building something yourself. I’ve built teams and companies and understand the joy of a build. But I’ve also seen what happens after the first celebration. When the first hiccup turns up, everyone scrambles to find a fix. And then it happens again, and soon enough you find your teams working at midnight every time there’s a release to fix the bugs that come out. The anxiety, the overwork, the fire-fighting. That’s when the real decision starts to reveal itself.
If a carrier chooses to build, they now own it forever. In the beginning, this can feel great and like such an accomplishment. However, with every new release, the complexity grows, and the technical debt multiples. The carrier’s team now owns the bugs, the hosting, and the security patches. The team also owns the less often thought about things: compliance changes, documentation, knowledge transfers as team members transition. Every change, every production issue that shows up at the worst possible time is on the shoulders of your team and multiplies the effort required over time.
In insurance, the business always changes as regulations, products, data sources, and customer expectations all shift. What worked three years ago may not be enough today, especially at the pace technology is now advancing.
The weight of keeping pace with change is where build decisions start to look different. The cracks in the foundation usually start becoming more obvious around year three.
By then, the original budget is gone, the original project team has changed, and often, the people who knew why certain decisions were made are no longer in the room. The system still works, but only because a handful of people know how to keep it standing. And now the carrier is not just running an insurance operation. It’s running a software maintenance organization.
I have watched carriers underestimate this over and over again. Not because they are careless or lack smart people in the room to find a solution, but because the first estimate only counts the build. It can’t possibly account for the entire life of the thing.
When you decide to build, you’re not making a one-time investment. You’re adding a permanent responsibility to the organization, along with permanent talent in the form of developers, quality assurance testers, infrastructure support, security oversight, and regulatory experts. You will also need people who can explain to that team why the business behaves a certain way. And over time, you’ll have to continue to maintain that team and institutional knowledge after the original builders are gone.
Custom development projects also often pull from the same people the business already depends on. Your best claims people get pulled into requirements sessions, operational leaders get pulled into design reviews, subject matter experts get pulled into testing, and IT teams get pulled into meetings about edge cases, exceptions, workarounds, and decisions that sound small until they take three months to unwind.
Everybody ends up doing two jobs, which usually ends up with neither job getting the attention it deserves. That inefficiency creates a hidden tax on the organization that isn’t a clear line item, but a tax still felt by the team and ultimately the policyholder.
Another trap in build decisions is what I call the blank sheet of paper problem. When everything is possible, everything is now also up for discussion. Teams get stuck spiraling on every workflow, every improvement that has been dreamed up over the last ten years, and every single exception the company has ever seen. The focused project suddenly becomes an attempt to build the perfect system.
There are good , configurable systems that solve problems. There are systems that improve over time because they are used across a real client base with real feedback and real pressure from the market. But there is no such thing as a perfect system, and chasing perfect is one of the most expensive things an organization can do.
I have seen carriers spend months of time and a lot of money building functionality for scenarios that happen less than one percent of the time. The edge case becomes the project, and before long, the system is harder to use, harder to maintain, and harder to explain, all because the organization could not say no to something that almost never happens.
What seemed like a strategy becomes scope creep with a business case wrapped around it. This is where buying software can actually create discipline. A good vendor has already had to make thousands of decisions shaped by implementations, production issues, client feedback, compliance requirements, user adoption, and the pressure of supporting multiple organizations over time.
Vendors don’t do this equally well, nor does every platform provide every functionality a carrier needs. That being said, a proven platform brings something a custom build usually does not have on day one: scar tissue. If it’s already been tested by other organizations and real users, chances are, the vendor and platform have had to answer questions that your internal team may not even know to ask yet.
Scar tissue matters especially in claims. The importance of claims cannot be understated. It’s where the promise of a carrier is put to the test. At the end of the day, a beneficiary doesn’t care whether the system behind the scenes is custom-built, vendor-built, cloud-native, legacy, or sitting on top of a policy admin system as long as they receive compassion and a quick payout in their time of need.
Your competitive advantage is not that you built the software yourself. Your competitive advantage is how well you serve people when the promise comes due. Software should support that, but if your company is constantly split between developing software and delivering insurance, it will have a split focus distracting from the true heart beat of an insurance company.
There are a few areas that will likely require custom development. The first is integration, the connective tissue between systems. Ecosystems are vital for keeping data moving correctly and serving the right information up to people at the right time. In many organizations, that is exactly where internal development should be focused.
There are also times when a carrier has something genuinely unique to its business model. This is not just a use case that a carrier does a little differently, but workflows that are truly unique, competitive differentiators that don’t exist anywhere in the market. Those workflows or capabilities generally can’t be configured in an existing platform and must be built.
Most processes that organizations believe are one-of-one are really industry-standard processes with a few local variations. They’re still important, but don’t justify building and owning an entire system.
Finding the line between the two requires asking why and understanding what truly differentiates you. Build what truly differentiates you. Buy what already exists, already works, and needs to keep evolving. Then put your energy into adoption, integration, process improvement, and getting the right people involved in the decision.
The people closest to the work usually know where the friction is. Claims examiners know what stalls out a claim. Call center teams know exactly when and where claimants and policyholders get frustrated with a company. The people who live in the systems every day know which steps are helping and which ones are just there because they always have. If you’re making a build vs. buy decision without those voices in the room, you’re probably missing the most important information.
I learned that lesson in my own company. At a certain point, as we moved from startup to scale-up, it became very clear that smart technical people weren’t enough. We needed people shaping the product who had actually lived the work, processed claims, and understood the pressure, exceptions, and handoffs. Bringing those voices closer to the product changed everything.
That’s as true for carriers as it is for vendors. The best technology decisions are not made in a vacuum but with the people who understand the work
I always come back to the same question. Not can you build it, but should you own it? Is it worth taking on maintenance, staffing, compliance, security, and technical debt?
Occasionally, the answer is yes. But a lot of times, it’s no, and there’s nothing wrong with that. The strongest companies are not the ones that build everything themselves, but the ones that know where their time, people, and capital create the most value.
For insurance carriers, that value is in underwriting risk, serving policyholders, managing claims, supporting distribution, and keeping the promise they made when the policy was sold.
The build decision almost always looks good on day one. The real test is whether it still looks good three years later. Next time a carrier considers, “Can’t we just build this ourselves?” it’s important to look back at where that decision will take in you three, five, or even ten years.
Because once you build it, the decision follows you.
