Gain Compliance builds solutions for the highly-regulated market of Insurance Statutory Financial Reporting. 

Notably, even to offer software for this use case, a vendor must undergo twice-annual certification by the NAIC (National Association of Insurance Commissioners).  To win business, Gain competes directly against five, long-established companies who have been servicing customers for over two decades. 

As the new kid on the block, our not-so-secret advantage is that we offer modern software; the incumbent providers, meanwhile, rely on legacy technologies for their offerings. To highlight a specific example of this difference: we offer the only solution that has no installed component. 

Gain’s software is, as expected from all modern software, accessible exclusively through a web browser and requires no “thin client” or any sort of downloadable element. Fundamentally, this allows our software to be:

  • More secure. Software with an installed client introduces the risk of malware and viruses. Insurance companies, in particular, are increasingly sensitive to third-party software that is downloaded and installed behind company firewalls or within its networks.
  • Better performing. Modern architecture has several orders of magnitude more computing power than legacy designs.
  • Easier to use. Modern technology allows for a customer experience that conforms to current expectations about design and usability. 
  • More reliable. As described in this excellent blog post, cloud-delivered software’s continuous delivery model eliminates the risks caused by the legacy software model of relatively infrequent, high-stakes software releases for patches and updates.

So, that’s the high-level, theoretical description of the advantages of modern software. But, how do the two types of software compare in the real world?

Well… in looking at our market, I can relate that the challenges created by legacy software are very real. Take the last bullet point – reliability – for example. Here a just a few selected examples of recent issues exhibited by the legacy software vendors in our market:

  • In 2018, one of our competitors was racing to meet a deadline for a major overhaul of features for a high-stakes release just ahead of a key filing period.  In the rush, a programming mistake rendered the software completely unusable; the inoperable product was pulled from the market for an entire filing cycle, and every single customer was left scrambling to find an alternative solution at the eleventh hour.
  • At the beginning of this year, a different vendor’s product update introduced a bug that resulted in incomplete data and bad filings for many customers. The error was not discovered until long after the fact (i.e. the regulators identified misfiled data). To compound the issue, affected customers were not able to refile corrected reports until a software patch had been issued and installed, a process that took several weeks longer.
  • Even more recently, a competitor introduced a bug to its product when distributing a software patch at the beginning of the Q1 filing cycle. Discovered much later at a particularly inopportune time, the issue precluded customers from completing their filing until a fix was available. Again, the creation, delivery, and installation of a patch was not timely.

Going a little deeper into how software is developed explains the root cause of these reliability issues. Looking at best practices in contrast of modern vs. legacy software:

Legacy, installed software = infrequent, large updates


Cloud-software = very frequent, small updates

Installed software creates a high-stakes process for updates: the infrequent release schedule means that there is a mad scramble to push the maximum amount of features to customers by a hard deadline. The complexity of introducing a large volume changes simultaneously, the pressure to deliver by a specific date, the inability to fix any issues easily (i.e. until the next scheduled release) – all contribute to an environment where reliability issues can be vexing.

Cloud-software, meanwhile, is less risky as code changes are both smaller and more frequent. The pressure to get features complete for a once-in-a-great-while, bundled update does not exist. Furthermore, any issues can be fixed quickly through rolling back to a prior state in the next incremental deployment.

In the blog post referenced above, Gain’s founder and CTO, Jason Jones, uses the analogy of a train schedule to describe the different environments for software release. A continuous release schedule (cloud-environment)  is like a subway – missing one is no big deal as the next one will be along shortly. Bundled releases (installed) are like long-distance trains that leave infrequently – it’s high pressure to get on board and the train is often delayed based on a more chaotic, involved, and stressful boarding process:

This is what happens when your software only updates every month, quarter, or year. The software release train is late, commuters are poorly served, some of them forgot their stuff because they were running late and any failure is a really big deal….

Software on a continuous delivery schedule gets delivered faster, better, and cheaper. If the software release train leaves every few hours, features go out as soon as they are ready. Missing any given release is no big deal. If something goes wrong with one train you can take it out of the system and let the rest keep on moving. 

Importantly, highlighting the reliability issues only scratches the surface. Usability, performance, security – all are similarly improved with modern software as well. 

Make sure to check out our other the blog posts, and follow Gain Compliance on LinkedInFacebook and Twitter.