Insurance Technology Diary
Episode 42: In out of the rain
Guillaume Bonnissent’s Insurance Technology Diary

Eight years ago a friend told me he’d decided to build a house. I assumed he meant he was going to make some rough sketches of his dream home, let his wife change them around, get an architect to draw it up properly, then hire some builders to do the business on an empty lot he’d inherited.
I was wrong. He meant he was actually going to build a house from scratch, with his own hands and tools. He said that by building it himself, he would save some money and get exactly the home he wanted, with no compromises, corners cut, or substandard materials or craftmanship. Meanwhile he and his wife would live comfortably in a rented property.
We all thought he was bonkers.
Eight years on, and he’s still in rented. Second-hand ladders in the new place remain the only access to the first and second floors. He learned electrics from an old You can do it DIY book, but had to pull out all his eBay-acquired wiring when an electrician told him his materials were fine 35 years ago, but didn’t meet current code.
He spent nearly a year on the plumbing alone (since, when the dosh ran out, he had to go back to his real job, and played Bob the Builder on evenings and weekends only). First he learned to solder a fitting and tighten a compression joint, then he refitted the whole lot after figuring out how join pipes without leaks. Then he fitted another third of it a second time, after it froze. (Note to self: insulation before plumbing.)
Why am I telling you this?
Lately I stumbled across a blog written by an insurance IT consultant. He advises insurance companies that have opted for an in-house build of technology platforms that handle various processes.
His argument is primarily about the pitfalls of third-party tech implementation, but he starts by saying what everyone knows: outsourcing provides temporary access to highly skilled professionals who already know how to do the work. It involves lower upfront costs, and it’s scalable, which is hugely attractive for small firms. What’s not to like?
Quite a bit, according to the consultant. He says that “the need and use cases of technology has [sic] gone well beyond the simple need for cost-cutting… [and] outsourcing creates even more fragmented workflows that … results in a patchwork of temporary fixes.”
This I assume is the feedback he has received from clients who have chosen to build in-house after unsatisfactory outsourcing experiences. But they simply used the wrong tech firms! The right software house will be utterly focussed on insurance, and will create systems which integrate seamlessly with legacy tech and third-party platforms, all knitted together by APIs.
Our in-house advisor also asserts that it’s straightforward to build a tech team. Take it from me, it’s not. At the most basic, even when you’ve found and recruited the correct, probably very-well paid individuals, they do not automatically become an effective development team. It takes many months before they work together well, and know each other’s strengths and styles.
The right tech team will already exist. It will be led by people who understand insurance AND coding, so will already know the difference between fac and a facility. It will think of functionality you haven’t thought of (because other people thought of it during previous deployments). It will already have tried various approaches to implement insurance-specific oddities such as underwriting authority limitations and sanctions-checking. It will get quickly to the heart of your company’s vision, strategy, and objectives, and build or fine-tune a system that suits you exactly.
There’s another really important reason to pay for third-party tech. Insurers and MGAs are valued by investors on the quality of their underwriting, not their technology. When it comes to valuations, technology is worthless (even when it’s critical to the quality of underwriting). So there’s no way to recover the tens of millions sunk into systems. Meanwhile, that shiny new tech development team looks, to investors, like nothing more than a bunch more mouths to feed.
My rental-residing friend has finally realised the folly of trying to build a house on your own. He’s hired a structural engineer, a master carpenter, a roofer, and a handyman. Even now they are focussed on restitution and repair. He should be under his own roof before the rains come.
Trying to build in-house is just as unlikely to yield quick, economical results as trying to build a house yourself. It’s especially true when compared to using an existing, experienced development team that has already been assembled and proven outside of your organisation, and has figured out how to steer clear of the rain.
