The Great Buy Versus Build Debate (And The Killer 3rd Option)

Insurers have spent decades arguing about core systems, the great buy versus build debate. The panels at every conference, the consultants, the procurement teams, all working through the same trade-off.

Build means control. You design exactly what you need and the system fits your business.

Buy means speed. Someone else has solved the problem, you implement their answer and move on.

Both arguments are familiar and both come with trade-offs that have become harder to live with. Building is slower and more expensive than anyone admits in the business case. Buying is more rigid than the sales pitch suggests.

There is a third option, firmly in the middleground, that most of these conversations skip past. Configure. For most insurers it is the one that actually makes sense.

The case against building

The argument for building has always been control. Build it yourself and you get exactly what you want with no compromises and no vendor roadmap dictating your future. In theory this is compelling. In practice it rarely works out.

Building a core insurance system from scratch requires skills that are increasingly hard to find. Developers who understand insurance are rare enough. Developers who understand your specific lines of business, your distribution model, your regulatory environment and modern software architecture at the same time are rarer still.

The timeline is almost always longer than projected. A project scoped at 18 months becomes three years. Budgets double. Key people leave halfway through and institutional knowledge walks out the door with them.

When you finally go live you have created something else. Technical debt. The system you built is now yours to maintain. Every bug is yours to fix, every upgrade your responsibility, every security patch and performance improvement on your plate while competitors launch new features on platforms that someone else is investing in.

McKinsey has estimated that insurers spend around 70% of their IT budgets maintaining legacy systems. Much of that goes on systems they built themselves years ago that now anchor them to the past.

Building made more sense when software changed slowly, when a system built in 2005 could reasonably be expected to last fifteen years without major rework. That world no longer exists. Customer expectations have shifted, regulatory demands have grown, distribution has fragmented and AI is rewriting the rules of what core systems need to do. Building for that level of change demands a level of ongoing investment that few insurers can sustain.

The case against buying

Buying should solve these problems. Let someone else build the platform, let them maintain it, let them invest in R&D, you just use it.

The trade-off is flexibility. Traditional bought systems are rigid. They come with pre-defined workflows and fixed data structures and a way of doing things that reflects how the vendor thinks insurance should work, not necessarily how your business operates.

Implementation becomes an exercise in adaptation. You change your processes to fit the system, build workarounds for the things it cannot do, request features that sit on a roadmap you do not control, behind other clients whose priorities differ from yours. The system works. But it does not fit.

This matters more as insurance becomes more competitive. Speed to market is a real differentiator and launching a new product in weeks rather than months can decide whether you win or lose a distribution partnership. A rigid system that needs vendor involvement for every change becomes the bottleneck.

Then there is lock-in. Once you are on a platform, moving is painful. Your data is structured their way, your integrations are built to their APIs, your team has learned their system. The switching cost creates leverage and the vendor knows it when renewal conversations come around.

Buying solves the maintenance problem and creates a dependency problem in its place.

Configure: the third option

Configuration sits between building and buying. You do not build from scratch because the platform exists, the core functionality is proven and the infrastructure is maintained by someone else. Updates, security and scalability are handled for you.

You do not simply accept a rigid system either. You configure it, shaping the platform to your business without writing code, using the no-code and low-code tools that modern platforms provide.

Product configuration, workflow design, underwriting rules, rating logic, document templates, user interfaces, all adjustable by your team, in your time, without waiting for a development cycle. The platform provides the foundation and you provide the specifics.

This is the middle ground between reliability and agility. You get an enterprise-grade platform that is tested and backed by a vendor investing in its future. You also get the agility to change. Launch a new product, adjust a workflow, respond to a regulatory shift, add a distribution partner, all without raising a change request and joining a queue.

The 95% nobody should want to build

The strongest version of the build argument is that configuration cannot handle the things that genuinely matter. The differentiated parts. The reasons your business is not like everyone else’s.

That argument deserves a closer look.

A core insurance platform handles a lot of things that are not differentiators. Task management. Address fields. Document storage. Basic reporting. User permissions. Audit logs. Workflow state. The plumbing every insurer needs and nobody wins on. Building that from scratch is spending senior engineering time on commodity functionality so you can feel like you own it.

Press most build advocates and the argument narrows quickly. What they want to control is the 5% of what they do that genuinely differentiates them. The rest of the system is just the cost of getting to that 5%.

Configuration answers this directly. You take a platform that resolves the 95% you were always going to need, and you build the differentiating 5% on top of it. Or you ask your vendor to build it for you as an extension.

This is usually where the build case collapses. If that 5% is important enough to justify constructing an entire core system from the ground up, it is surely important enough to pay your vendor a fraction of that cost and time to build it as an extension on a platform that already works. If you are not willing to pay for it as an extension, the harder question is whether it was ever as differentiating as you told yourself it was.

Most of the things used to justify building from scratch turn out, on closer inspection, to be commodity functionality dressed up as special, or genuinely differentiated features that could have been built on top of a working platform in a fraction of the time.

What configuration looks like in practice

Configuration is not a new word, but the depth of what can actually be configured has changed dramatically.

A decade ago, configuration meant adjusting some settings. Changing a label, tweaking a threshold, anything more substantial still required development. Modern platforms work at a different level.

Take product building. A configurable platform lets underwriters or product managers define a new insurance product without developer involvement. They set the risk fields, the rating logic, the rules for referral, the documents generated and the questions asked at quote stage. They test it, refine it and push it live.

Hayes Parsons used this approach to take a new yacht insurance product from specification to market in ten days. The point is not the speed in isolation. It is that the speed came from the product team owning the build directly, without a developer queue sitting between the underwriting decision and the live product.

Arma Karma went further. They stood up an entire policy administration platform with Genasys in seven days. Not a single product inside an existing implementation but the whole system from zero. The difference between that and a traditional implementation is not measured in weeks. It is measured in months and quarters. That is what depth of configuration makes possible when the platform underneath is built for it.

Workflow design works the same way. A configurable platform lets operations teams define how work moves through the business. What triggers a task, who it gets assigned to, what happens when it is completed, what escalates and when. This is not a diagram handed to IT to implement. It is a workflow the business builds and owns.

Integrations sit in the same category. Open APIs let you connect to external systems without custom development. A rating engine, a payment gateway, a third-party enrichment service, your general ledger. The platform handles the plumbing and you decide what connects to what.

Why Buy versus Build versus Configure matters now

A few shifts have moved configuration past the old build-or-buy debate.

The talent shortage is real. The people who built your legacy systems are retiring. Developers who understand COBOL are expensive and getting harder to find. Relying on scarce technical skills for every business change is not sustainable. Configuration moves power to the people who already understand the business: underwriters, product managers and operations leads who know what needs to change and why.

Speed has become a competitive advantage in its own right. The MGA market has grown rapidly and the firms winning are the ones who can launch products quickly, respond to market shifts and onboard new distribution partners without months of lead time. A rigid system cannot keep that pace.

The regulatory environment is tightening at the same time. The FCA has drawn a direct line between legacy infrastructure and operational fragility, and operational resilience is moving from good practice toward compliance requirement. Configuration allows faster response to regulatory change because a new requirement can be reflected in workflows, documents and rules without waiting for a software release.

The questions to ask

If you are evaluating platforms the question is no longer just build or buy. It is how much of the platform you actually control once it is yours.

Ask how much can be configured without code and ignore the marketing answer. Get specific. Can you build a product end to end? Can you change a workflow? Can you add an integration?

Ask who does the configuring. If every change still requires the vendor, you have bought a rigid system with extra steps. Configuration should be in your hands, not theirs.

Ask how deep configuration goes. Surface-level settings are not enough. You need to shape the system to your operating model rather than adjust the cosmetics.

Ask what happens when you need something that cannot be configured. No platform covers every edge case. The question is what the path looks like when you hit the limits. Is there an extension framework? An API layer? A way to add capability without forking the core?

Get straight answers to those four questions and the choice in front of you stops being build versus buy. It becomes a question of how much of the platform will still work the way your business works once the implementation team has gone home. Configuration is what keeps that answer in your hands.