The most valuable tools in insurance are being built by people who spent their careers inside the problem. That same group is the easiest to filter out and the industry can’t afford to.
The most valuable software being built in insurance right now isn’t coming from Silicon Valley. It’s coming from inside the industry.
Not from career engineers who picked insurance as a vertical and learned the words. From practitioners. claims people, underwriters, reinsurance analysts, and compliance specialists who spent years living inside a problem, know exactly what needs to be built, and have now picked up enough technical skill to build it themselves.
That combination used to be almost impossible to find. The domain knowledge takes decades to earn. The engineering used to take a team and a budget. So for most of the industry’s history, the people who understood the problem and the people who could build the solution were two different sets of people, and the gap between them is where a lot of bad software got made. You’d get a technically clean product that misunderstood how a reserve actually moves, or how a bordereau actually reconciles, or what a multi-state comp claim actually requires instead of one that was built to solve that actual wrong problem.
What’s changed is that the build side got cheaper and faster. The barrier that used to require a funded team now clears for one person who knows what they’re doing. And the people walking through that door first are the ones who already carry the hard part with the domain knowledge that no amount of engineering talent can shortcut.
The expertise is the scarce thing, not the code
This is the part the industry undervalues, because it’s invisible on a vendor questionnaire.
In a field this specialized, the builder’s experience is the most important control in the product. A team building a claims tool without understanding jurisdiction-specific rules, coverage interpretation, or regulatory obligations will produce systemic errors that create real liability quietly, at scale, in ways that don’t show up until a regulator or a reinsurer finds them. A practitioner who encoded those rules correctly from the start won’t. The expertise isn’t a nice-to-have wrapped around the software. It’s the thing keeping the software from being dangerous.
Code can be reviewed, tested, and fixed. Judgment about how insurance actually works can’t be reviewed into existence. It has to already be there. The practitioner-builder brings the part you can’t audit for, and the industry treats it as the part that doesn’t count.
And this is exactly the group that gets filtered out
Here’s the hard irony. The builders who carry the most valuable thing are also the ones least equipped to survive how insurance buys software.
A well-funded startup can absorb a 90-day review without blinking. It has legal staff to negotiate data processing agreements, compliance people to grind through an 850-question security assessment, and investor money to fund a SOC 2 audit in year one. None of that makes its product better. It just makes the product easier to buy.
The practitioner-builder usually has none of that and this is not because the product is less secure, but because the capital is in the product, not in the paperwork. Their software often runs on the same certified cloud platforms the big vendors use, inherits the same compliance posture, and isolates data at the database layer as well or better. What it lacks is a department whose only job is to make procurement comfortable.
So when the review process leans on the size of a vendor’s compliance team as a stand-in for the security of its software, and it often does, without meaning to, it ends up weighing the org chart more than the substance. The largest, most expensive vendors clear the bar. The most domain-accurate, most efficiently built tools, made by the people who understand the problem best, are the ones most likely to get caught in the filter. Not by anyone’s intent. Just by how the filter was shaped.
A new kind of builder might call for a new kind of front door
It’s worth saying that none of this is anyone’s fault. The way the industry evaluates new software was built carefully, for good reasons, around the kind of vendor that used to show up with a company, with a sales team and a security department and a long road of references. Those assumptions made sense. I was a part of those decisions and the process still make sense for that kind of vendor.
What’s new is that the builder doesn’t always look like that anymore. Sometimes it’s one person who knows the problem cold and has built a focused tool on the same certified infrastructure the big platforms run on. The old questions weren’t designed with that person in mind, not because anyone got it wrong, but because that person didn’t exist at any scale until recently.
So maybe the interesting question isn’t whether the process is broken. It’s whether a path to innovation built for one era still fits the next one. When the most valuable builders start arriving through a door the industry didn’t expect them to use, it might be worth asking what a door built for them would look like. This door needs to be just as careful, but calibrated to what these tools actually are rather than to how big the company behind them is.
That’s a more hopeful version of the same conversation. The talent is showing up now, on its own, without being recruited. The carriers that find a way to meet it quickly, and on terms that fit, get access to something the industry has never had in volume before: people who don’t need the problem explained to them, who’ve already lived through the failure modes, and who can ship a fix in weeks.
The recurring note from this year’s industry gatherings, and I just saw this earlier this month at InsureTech Insights USA, is that AI is widening the gap between the organizations that move and the ones that don’t. The movers aren’t always the ones with the biggest budgets. They’re often just the ones who found a way to say yes to the right small thing.