What is a single code base?

A single code base: what is it, and why is it important?

No matter how tech-savvy you are (or not) you’ll have come across single code lines.  Perhaps you don’t realise when you have, but you have.  If you use accountancy software for example (e.g. Sage or Xero), you know that there are lots of other companies using it and that there are periodical updates to the software.  It gets better every now and then.  But you don’t notice when it happens, you just log in and there it is: better. 

The same is true for Ignite’s insurance software.  We have one version of our software and we update it every two weeks to make it better.  The updates are often small but they keep all our clients at the forefront of the system’s capabilities.

We do this even though it makes development slower.  It’d be much quicker to simply clone the latest version of your system and give that to a new client, rather than to merge all the functionality and fixes you’ve done for all the previous clients into a single code line.  

Why is this important?  Because lots of other policy administration software companies don’t use a single code base.  Instead, they have a major version upgrade they release every 6 or 12 or even 24 months. When there is a new version the clients are asked to pay for the upgrade. That’s fair enough, everyone has to earn money, but what if you don’t buy the upgrade?  Answer: your version of the software gets left behind and you’re stuck on a time-bomb of a system.  And if you try to upgrade in the future it might not work, because the people who used to work on your old version one, or two, or five years ago have forgotten how it works, moved to another company or retired.  Then hey presto: you’ve got a legacy system.  Suddenly upgrading is a business risk, and you’re going to have the same problem again in one, or two, or five years. 

As a software house, if you don’t have a single code line you end up with a tangle of systems a bit like human evolution’s ancestry as in the diagram shown: lots of defunct versions that get left behind along the way and go extinct. 

One of our esteemed competitors recently announced that they’re moving to a single code line.  Great news, good idea.  Two questions: what happens to all the poor buggers who’re on the old versions?  And secondly, do you really expect us to believe that you’re going to stick with a single code line in the future?  I’ll believe it when I see it.  

So if you’re on a system that has the words Version 6 (or similar) after it, then you might want to buy a platform that runs a single code base in the future…

Scoping your Requirements

So you’ve made the decision to buy a new Policy Administration System. Your existing system is too slow/buggy, changes are difficult or expensive, maybe you want to set up a new product line or brokerage, or maybe Covid-19 has pushed forward your digital roadmap.

Where to begin? Well, to start with you Google ‘insurance software’ or look at the ads in the Insurance Times. There are lots of companies out there, but finding out which is right for you is going to be hard. You contact a few but how to tell if they’re going to do everything you need? There are big companies and small companies. How do you compare apples with apples?

Bit of advice: you need to come armed with a set of requirements. You won’t get very far asking what systems do because they do an awful lot, and lots may not be relevant to you. Ideally, you need a Business Requirements document, or what we call a Scope.

The bigger and better this Scope is, the more likely you are to choose the right company and get the right system.

Shocking admission: Ignite Broker might not be the right system for you! And that’s fine with us. The last thing we want to be doing at Ignite is providing systems to clients who could get better ones elsewhere. There are some great tech products out there and if there is a better fit for your business then go for that.

Ignite is particularly good at certain things – e-commerce, digitisation, integrations, accounting, real-time pricing, the list goes on – but we’re not so good at others – open market products, paper-based operations, London markets, the list goes on.

The scope is all about defining what is important to your company and therefore which system provides best for those requirements. If you’ve got the expertise and time to write a detailed scope document (which can run to hundreds of pages) then go for it! If you haven’t then Ignite can help. The first stage of any project – before contracts are signed. Yes, we charge for it, but it will pay for itself many times over in the long run.

The scope document is systems agnostic, and you’re welcome to show it to other software companies. This way everyone knows what you need from your system and you can truly compare the systems in front of you.

So if you’re looking for a new system, contact us for a demo and talk to us about how a scope document can help you make the right systems choice.

One word of warning: if any company ever says they can build what you’re looking for, don’t buy it. The functionality you need is out there somewhere and comes out-the-box. In a good scope, bespoke work should be at an absolute minimum.