Why configuration beats customisation

What bespoke code costs insurers in change requests, upgrades and lock-in, where configuration has its limits, and how to test which one a vendor is really selling.

There’s a moment in almost every insurance software evaluation when the conversation stops being about the software and starts being about the past. The demos are done and the shortlist is down to two. Then someone from underwriting or operations leans forward and asks: “Can it do exactly what we do today?”

Most vendors will say yes. Some of them will mean it. What they usually mean is “yes, with some customisation”, and that phrase deserves a lot more scrutiny than it normally gets, because it decides what the next ten years of your business will feel like.

I spent the first part of my career as an underwriter at AXA, Aviva, RSA and COBRA Underwriting, and I’ve spent the last few years on the vendor side. I’ve been on the receiving end of slow system changes, and I’ve sat in the meetings where vendors work out how to scope them. This article is my attempt to explain, in more detail than most buyers ever get, why the choice between configuration and customisation matters so much, and how to tell which one you’re actually being sold.

Two words that get used as if they mean the same thing

They don’t, and a lot of confusion in software buying comes from treating them as interchangeable. Vendors are partly to blame. “Highly configurable” has become one of those phrases that appears on every website, including the websites of platforms where almost every change needs a developer.

So here are the definitions I’ll use for the rest of this piece.

Customisation means changing the software itself. A developer writes new code, or alters the vendor’s existing code, so that the system does something it couldn’t do before. That code sits outside the vendor’s standard product. Sometimes the vendor or an implementation partner maintains it for you, and sometimes your own IT team inherits it. In every case, your copy of the software is now different from everyone else’s.

Configuration means changing how the software behaves using tools the software already provides. You build a new product, add a rating factor, write an underwriting rule, change a referral threshold or design a policy wording template, all through screens and builders inside the platform. Nobody touches the underlying code. Every customer is running the same software underneath, and the differences between them live in configuration data.

There’s a middle ground worth naming too, which I’ll call extension. This is where you add something alongside the platform without changing the platform itself: an integration built on the vendor’s documented APIs, say, or a pricing engine that the core system calls out to. Extension can involve plenty of code, but because that code talks to the platform through published interfaces, it doesn’t interfere with the core.

If you picture these as a spectrum, configuration sits at one end and customisation at the other, with extension in between. The further a change sits towards the customisation end, the more it will cost you over time, and the harder it becomes to undo.

What happens when you need to change something

The clearest way to see the difference is to follow a single, ordinary change through both kinds of system.

Say you’re an MGA writing commercial property. Your capacity provider has looked at the last two years of claims and wants you to load rates for buildings with flat roofs over a certain age. It’s a sensible request, and the kind of thing that happens all the time.

On a heavily customised system

Your underwriting manager writes up the requirement and sends it to whoever owns that part of the code. Someone needs to work out where the rating logic lives. On a system that has been customised for years, that can take a while in itself, because the logic for property rating may be spread across several modules written by different people at different times.

Then the change gets scoped and estimated. It joins a queue behind every other change request from every other department. When a developer picks it up, they write the code and hand it to testing. Testing finds that the new loading interacts badly with an older discount someone added three years ago, so it goes back to the developer. Eventually it’s deployed in the next release window, which might be monthly or quarterly.

If you’re lucky, the whole thing takes four to six weeks. If the change touches anything else, or the one developer who understands the property module is on holiday, it takes longer. And if the developer works for your implementation partner, you’ll get an invoice for the privilege.

Meanwhile you’ve been writing flat-roofed buildings at the old rate for six weeks, which is exactly what your capacity provider asked you to stop doing.

On a configured system

Your underwriting manager, or a product specialist on their team, opens the rating configuration for the product. They add the roof type and age as a rating factor if it isn’t already captured, then set the loading. They run it against a set of test quotes to check the results look right. The change goes through whatever approval your governance requires, and then it’s live.

Version control records every change and who made it. If the loading turns out to be wrong, rolling it back takes a click instead of a release.

That can happen in a day. It’s the same change and the same business outcome, but the cost is a fraction and the people who understand the risk are the ones making the change.

Why this matters more than it used to

This would be a minor operational point if insurance products rarely changed. They change constantly, and the pressure to change them quickly keeps growing.

Regulation is one reason. When the FCA’s general insurance pricing rules came into force on 1 January 2022, following policy statement PS21/5 in May 2021,¹ insurers writing home and motor business had to make sure that a renewal price was no higher than the equivalent new business price. That meant reworking renewal pricing logic across entire books. Firms whose pricing lived in configuration could make those changes themselves and test them properly. Firms whose pricing lived in bespoke code found themselves competing for developer time with everyone else in the market who had the same deadline.

The Consumer Duty, which came into force in July 2023, added an ongoing requirement to show that products offer fair value.² Fair value reviews regularly lead to changes in pricing and wording, and they keep coming.

The market cycle is another reason. Marsh’s Global Insurance Market Index has now recorded falling commercial insurance rates for several consecutive quarters.³ In a softening market, the businesses that can reprice a line or tighten appetite in days have a real advantage over the ones that need a quarter. A six-week change request queue is six weeks of writing business at a price you’ve already decided is wrong.

The upgrade trap

If the waiting is the cost you notice every week, the upgrade is the cost you notice every few years, and it tends to be much bigger.

Software vendors release new versions regularly. Those releases contain new features, performance improvements, new integrations and, most importantly, security fixes. On a platform where every customer runs the same software, upgrading is the vendor’s problem. They test and release the new version, and your configured products carry on working on top of it.

Customisation breaks that model. If your copy of the software contains bespoke code, every upgrade raises a question nobody wants to answer: does our code still work with the new version? Someone has to find out, and then someone has to fix whatever broke. On a system with years of accumulated customisation, an upgrade becomes a project in its own right, with its own budget and risk register.

Faced with that, a lot of insurers make a rational short-term decision and stop upgrading. They stay on a version that’s five or even eight years old because moving forward would cost more than standing still. The vendor keeps releasing improvements, and they can’t use any of them. Their system gets older every year, and the gap between it and the current version keeps widening until the only realistic option is a full replacement.

Plenty of insurers are in exactly this position, and most of them got there one reasonable customisation at a time. Nobody sets out to build an unupgradeable system. Each individual change made sense when it was made.

The cost that never appears in the business case

When an insurer builds the business case for a new platform, the costs that go in are the obvious ones: the licence or subscription fee, the implementation, the data migration and some internal project time. What rarely goes in is the cost of keeping customisations alive for the next decade.

McKinsey surveyed 50 CIOs at large financial services and technology companies in 2020 about technical debt. The CIOs estimated that technical debt amounted to 20 to 40% of the value of their entire technology estate before depreciation. They also said that 10 to 20% of the technology budget meant for new products was being diverted to resolving issues related to that debt.⁴

Bespoke code is one of the biggest sources of technical debt there is. Every customisation has to be maintained and tested at each upgrade. It also has to be documented well enough that someone who joins in five years’ time can understand it, which is rarely the case.

To make that concrete, here’s an illustrative example. The numbers are made up, but the shape will be familiar to anyone who has run a customised platform.

Imagine a mid-sized MGA raising 30 change requests a year to its policy administration system. Each one takes an average of four developer days once you include scoping, building, testing and deployment. At a day rate of £750, that’s £90,000 a year spent on changes that, on a configurable platform, the MGA’s own product team could make in a fraction of the time. Add an upgrade project every three years at, say, £150,000, and the customisation habit costs around £140,000 a year before anyone has counted the business written at the wrong price while changes sat in the queue.

Cost of customisation (illustrative)	Working	A year
Change requests	30 a year × 4 developer days × £750 a day	£90,000
Upgrade projects	£150,000 every three years	£50,000
Total	Before business written at the wrong price	£140,000

None of that was in the original business case, and all of it was a consequence of choices made during implementation.

Who actually understands your system?

There’s a softer cost that’s harder to put a number on, and it’s the one that worries me most.

On a heavily customised platform, the knowledge of how your products work tends to end up in the heads of a small number of developers. They know why the commission calculation has that strange exception for one broker, and which piece of code nobody is allowed to touch. When one of them leaves, a meaningful slice of your understanding of your own business leaves with them.

That’s a dependency problem, and it gets worse if the developers belong to an implementation partner. If the relationship sours or the partner raises its day rates, you have very little leverage. Your products are written in their code.

Configuration keeps that knowledge in the platform and in your own team. The rules are visible on screen. Anyone with the right access can see how a product is built and what triggers a referral. Training a new product manager means teaching them the platform, which they can then use across every product you have.

Configuration isn’t free either

It would be easy to write this article as though configuration solves everything. It doesn’t, and anyone who tells you otherwise is selling something. I’m also selling something, so I’ll be straight about the limits.

First, configuration needs skill. A no-code product builder is still a tool for building insurance products, and the person using it needs to understand both the tool and the product. You’ll want people on your team who know the platform well, whether they come from underwriting or IT. Those skills are far easier to find and train than knowledge of a bespoke codebase, but you still have to invest in them.

Second, configuration needs governance. When changes are easy, people make more of them, and that’s mostly a good thing. It does mean you need proper controls over who can change what and who signs changes off. A good platform makes this easier with role-based permissions, test environments, version history and audit logs, but the discipline has to come from you.

Third, a configurable platform has edges. There will be requirements it can’t meet out of the box. When you hit one, you can change the requirement, live with a manual workaround for now, wait for the vendor to add the capability for everyone, or build an extension that sits alongside the platform. What you should be very wary of is anyone offering to change the core code just for you.

Finally, “configurable” means different things on different platforms. Some vendors call a system configurable because it has a lot of settings, while anything beyond those settings still needs their professional services team. The only way to find out which kind you’re looking at is to test it, which brings me to the most practical part of this article.

How to tell what you’re really being sold

Vendor websites won’t tell you, because almost everyone claims to be configurable. Here’s how I’d test that claim in an evaluation.

Ask them to change something live

This is the single most revealing thing you can do in a demo. Come prepared with a realistic change, such as a new rating factor or a new question on the proposal form. Ask the vendor to make it in front of you, then run a quote to show it working.

A platform built on configuration will handle this in minutes, and the person doing it may well be a product specialist with no development background. A platform that relies on customisation will usually find a reason to do it later.

Read the statement of work

The implementation proposal tells you more than the sales deck. Look at how much of the work is described as configuration and how much as development or customisation. Look for day-rate cards attached to change requests after go-live. If the proposal assumes a steady stream of paid change requests in years two and three, that tells you how the vendor expects your relationship to work.

Ask about upgrades

Ask what proportion of customers are on the current version, and how long the average customer takes to adopt a new release. Ask what the last upgrade cost a typical customer. A vendor whose customers are all on the latest version, with no upgrade fees, is running a standard platform. A vendor who changes the subject probably isn’t.

Talk to long-standing customers

Reference customers who went live last year will tell you about the implementation. Customers who have been on the platform for five years or more will tell you what it’s like to live with. Ask them how long their change requests take and whether they’ve kept up with upgrades. Ask the vendor for those references specifically.

Check who owns the code

If any custom work is proposed, find out who owns the resulting code and what happens to it at each upgrade. Get the answers in writing.

Start with why the requirement exists

There’s one more point that I think gets missed in most evaluations.

When a team says the new system needs to do exactly what the old one does, they’re usually describing the old system’s limitations as much as their own needs. Workarounds become habits, and habits become requirements. A manual step that exists because the old system couldn’t send a document automatically ends up written into the specification for the new one.

Before agreeing to any customisation, it’s worth asking why the requirement exists at all. A surprising number of them disappear under that question. Others turn out to be things a modern platform already handles in a different and better way. The ones that are left are usually worth meeting, and most of the time configuration or a well-built extension will do the job.

Moving to a new platform is one of the few moments when you get to rethink how you work. Spending it rebuilding the old system’s quirks in new code is an expensive way to waste it.

How Genasys approaches this

I’d be leaving something out if I didn’t explain where we stand.

Genasys is built on the configuration side of this argument. Our customers’ own teams build and change products, rating, rules, workflows and documents in no-code tools, with version control so every change is recorded and can be rolled back. More than 450 documented API endpoints and webhooks handle connections to portals, payment providers, pricing engines and partners, which means extensions sit alongside the platform without changing it. Every customer runs the same platform underneath, so upgrades reach everyone.

That’s what made it possible for Genasys to deliver Arma Karma’s policy administration platform in one week, and for King Price to replace its legacy system in six weeks. Neither project involved rewriting the platform to fit the customer.

We still say no sometimes. When a customer asks for something the platform can’t do, we’d rather add it as a capability every customer can use, or help them build an extension, than create a private version of the software that will cause them problems at every upgrade.

Questions to take into your next evaluation

If you only take one part of this article into your next software evaluation, take this list.

1. Can you make this change live in the demo, and can someone who isn’t a developer do it?
2. How much of a typical implementation is configuration, and how much is custom development?
3. After go-live, can our own team build and change products without raising a change request?
4. What proportion of your customers are on the current version, and what did the last upgrade cost them?
5. If any custom work is involved, who owns that code and who maintains it at each upgrade?
6. Can we speak to a customer who has been on the platform for more than five years?

I’d put more weight on the answers than on the demo. The demo shows you the software on the day you buy it, and the answers tell you what living with it will be like in year five.

Show References Hide References

1. Financial Conduct Authority. PS21/5: General insurance pricing practices market study. 2021.
2. Financial Conduct Authority. PS22/9: A new Consumer Duty. 2022.
3. Marsh. Global commercial insurance rates fall 6% in Q2 2026. 2026.
4. McKinsey & Company. Tech debt: Reclaiming tech equity. 2020.