The No-Code Mirage: The Hidden Costs of No-Code Builds for Insurers

When insurers are contemplating embarking on an IT transformation, one of the most important decisions they face is “Build vs. Buy.” Can they purchase a software solution that solves their need at the right price point, or do they need a completely bespoke setup that will take longer to implement, not benefit from constant industry and technology advances, and ultimately cost much more to build and maintain?

Another option has arisen in recent years that tried to differentiate itself from the two approaches by taking a middle path. Low-Code / No-Code (LCNC) - or sometimes known as codeless - solutions offered insurers promises of the customization of Build solutions with the rapid development time and lack of maintenance that come with purchasing software.

Unfortunately, many insurers have come face-to-face with a harsh reality: a No-Code Build is still a Build. 

And instead of getting the benefits of both Build and Buy, they get stuck with the downsides of both - and some other major drawbacks, to boot.

Let’s take a closer look at how a No-Code build stacks up relative to traditional Build vs. Buy when it comes to complex IT transformations:

• Time to value - Build transformations are typically a multi-year affair that frequently miss timelines. Buy timelines can vary as well, but tend to be far shorter, with some systems like Kalepa’s Copilot able to deliver value on day 1. Complex No-Code setups typically wind up taking multiple years as well (we have even seen organizations in year 2 of a deployment still “gathering requirements”), and often become never-ending slogs. As one industry friend recently told me, “No-Code setups are like the city of London - It will be great when it’s finished. It’s just never finished.”
• Impact - For both Building and Buying, the impact can be highly variable and uncertain - many of these projects ultimately fail. The big difference is that the best Buy solutions often can demonstrate value in highly specific POCs in production to give you confidence before making a significant investment. For both Build and No-Code, that’s not the case at all - it takes over a year just to discover if you will get any value whatsoever, and demos can differ radically from what is delivered in production.
• Cost - In general, Buy solutions tend to have lower upfront costs than Build solutions (with the best Buy solutions looking like long-run bargains in comparison). But for complex transformations, the recurring costs of long-term development and support ruin the long term advantage of Build as well. No-Code solutions have the worst of both worlds, as you are responsible for paying platform fees and upgrades and maintenance fees (or labor) for as long as you’re tied to the platform.
• Maintenance - One of the clear advantages for Buy over Build - in the SaaS space, at least - is maintenance, since the vendor is responsible for maintaining and upgrading the product. No-Code faces the same issue as build in this regard, as your team remains responsible for all the maintenance and upgrades, unless you outsource to high-cost system integrators. The downsides of No-Code are exacerbated if you’re considering stitching many vendors together on a No-Code base: that means many more failure points with all of the work falling on your team.
• Customization - Build solutions tend to be much more customizable than Buy solutions, since everything can be built for your specific use case. But this can also lead to the “customization trap,” a slippery slope of additional custom builds, increased complexity, reduced scalability, extra failure points, manual workarounds, and more. No-Code builds come with an exaggerated version of the issue, since even more complex customizations are required to get around the limitations of the underlying platform, creating a Frankenstein-like setup that can collapse under its own weight.
• Expertise - Buying a product ensures that you are dealing with experts in the software you are purchasing, whereas a Build requires that expertise to be assembled, developed, and documented in-house. But more than that, Buy solutions are typically at the forefront of developing new technologies like AI, which often take years to work their way into Build solutions. No-Code presents major challenges in the expertise department, as it requires you to maintain or outsource to a team with specific expertise in building with a niche No-Code product (instead of hiring developers for a common programming language), and leaves you in the dust when it comes to new technology advances.
• Control - Build solutions usually provide more control than Buy solutions, with the obvious caveats that expertise and bandwidth can be limitations. No-Code solutions are the worst of all worlds in this case, as you can’t “assemble the blocks” if the No-Code vendor still has to build the blocks you want (the technical debt is now on their end), and you still have to deal with expertise and bandwidth issues.

To help summarize the comparison of the three roads - Build, No-Code Build, and the best Buy solutions on the market - we made the chart below:

When it comes to complex implementations, No-Code solutions have significant drawbacks that should make any insurer question whether to center their architecture around them. 

The oft-cited ‘Lego’ analogy works well here - Legos are an excellent tool for quickly building a small toy house that looks how you want, without having to break out the power tools. At the same time, If you wanted to build a real house, you would never in a million years make it with Legos. You either buy a house that already exists, or you build a new house with tools that are equipped for the job. 

Most insurers have fallen for this trap in the past. Almost every insurer has orchestrated a complex “build” that centers many processes around a particular No-Code / Low-Code software that is customizable by business users and much quicker to stand up than coding from scratch.

It’s called Microsoft Excel.

For all its many strengths, Excel is just not made for bearing the IT weight of an entire organization. In 2024, you would be crazy to propose centering your architecture on Excel for underwriting, rating, or claims handling. Many insurers are dealing with exorbitant pain in trying to transition away from their “Excel Builds,” and what seemed like perks to this approach in the beginning have become massive drawbacks in the years since.

For insurers looking to decide between Buy vs. Build for complex transformations, there are many considerations to take into account. But one thing is for sure: there is no Option C - a No-Code Build is still a Build.