Every major insurance technology decision comes down to three options: build it, buy a platform, or automate what already exists. Most insurers get this wrong by applying the same answer to every question. This post provides a clear decision framework: when each option creates value, when it creates technical debt, and why most real decisions are hybrid — with automation increasingly winning on speed, cost, and reversibility.
Three Columns. Four Months. One Recommendation by Thursday.
The slide on screen shows three columns. Build. Buy. Automate. The CTO has been working on this decision for four months. The claims management system the insurer has been running on for eleven years is no longer fit for purpose. It cannot support real-time FNOL intake. It does not expose APIs that the digital team needs for the customer portal. It was last updated meaningfully in 2019. The maintenance contract costs £840,000 a year for a system that handles a process the business increasingly cannot do competitively.
Option A: build a proprietary replacement. Estimated cost: £4.2 million. Timeline: 28 months. Risk: high. Option B: buy a market platform. Estimated cost: £2.1 million over three years including implementation. Timeline: 12 months to go-live. Risk: medium. Three vendors have been shortlisted. None is a perfect fit. All require configuration work. Option C: automate and extend the existing system. Estimated cost: £480,000. Timeline: 14 weeks to first workflow. Risk: lower. The process problems get addressed without replacing the system that underlies them.
The board wants a recommendation by Thursday. The CTO knows that whichever option she recommends, she will be accountable for it for the next five years.
Key Figures
| Figure | What it means |
|---|---|
| 68%[1] | Of large insurance technology implementation projects run over budget or over time, with the average overrun on build projects being 40% of the original estimate. Buy projects overrun at a lower rate but with higher average implementation complexity than initially scoped. |
| 60–70%[2] | Of total IT budget at legacy-dependent insurers consumed by maintaining existing systems rather than investing in new capability. This proportion has grown year on year since 2020 as maintenance costs on ageing infrastructure compound. |
| 14 weeks[3] | Average time to first measurable outcome for AI and workflow automation deployments in insurance operations, versus 12 months for bought platform go-lives and 28 months for significant build projects. |
| 3.2×[3] | Average return on AI automation investment in insurance operations over a 24-month deployment period, based on documented deployments across claims, underwriting, and finance functions in UK and European markets. |
| 42%[2] | Of insurers that chose a buy option for a major technology component reported that vendor lock-in and configuration limitations became a material constraint on their operating model within three years of go-live. |
Why Insurance Technology Strategy Decisions Are Harder Than They Look
Insurance technology strategy is the discipline of making technology investment decisions that compound competitive advantage rather than creating the technical debt that slows the next decision. A clear framework does not make the decision for you. It makes the decision-making process consistent, the tradeoffs explicit, and the criteria visible enough to defend in a board meeting and revisit objectively when the outcome is reviewed.
When to Build
The conditions that justify proprietary development
Build is the right answer in a narrow set of conditions: when the capability you are developing is a genuine competitive differentiator, when no market platform exists that addresses your specific requirements at the required scale, and when your organisation has the engineering capability to deliver and maintain the solution through multiple iterations. All three conditions must be true simultaneously. If any one is absent, build is almost certainly the wrong choice.
The competitive differentiator condition is the most frequently misapplied. Insurers regularly conclude that their claims handling process, their underwriting workbench, or their policy administration workflow is a differentiator that justifies proprietary development. In most cases it is not. The capability that differentiates an insurer commercially is the quality of its underwriting judgement, the strength of its distribution relationships, and the speed and fairness of its claims handling. The systems that support those capabilities are infrastructure. Building proprietary infrastructure is expensive, slow, and creates maintenance obligations that persist long after the original development team has moved on.[1]
When to Buy
The conditions that favour a market platform
Buy is the right answer when a mature market platform exists that addresses the capability gap, when the process the platform supports is not a differentiator, and when the speed to value from a bought solution materially outweighs the configuration cost. The most common failure mode in buy decisions is underestimating configuration complexity. A platform that covers 80% of the insurer's requirements out of the box will cover the remaining 20% through configuration — and that configuration work is not free. It requires the insurer's subject matter experts, the vendor's implementation consultants, and the insurer's integration team to work together for months, often in parallel with live operations.
The 42% of insurers who reported vendor lock-in as a material constraint within three years typically encountered it because the configuration required to make the platform fit their operating model created dependencies that made switching prohibitively expensive.[2] Vendor selection should evaluate: the platform's API architecture and integration capabilities; the vendor's product roadmap and its alignment with your three-year requirements; the total cost of ownership including implementation, configuration, licensing, and support; and the references of comparable insurers who have deployed the platform in a similar operating context.
When to Automate
The conditions that make automation the fastest path to value
Insurance IT modernisation does not always require replacing the system that is causing the problem. In many cases, the system is adequate. The process around it is not. Manual data entry, inconsistent decision-making, slow handoffs between teams, and the absence of real-time workflow visibility: these are process problems that AI and workflow automation can address without touching the underlying system.
Automate is the right answer when the underlying system holds clean, structured data that an automation layer can read and write to; when the process problem is one of consistency, speed, or volume rather than fundamental capability; and when the organisation needs measurable outcomes faster than a buy or build timeline allows. The 14-week average time to first outcome for automation deployments, versus 12 months for bought platforms, is the decisive commercial argument in many situations.[3]
The failure mode in automation decisions is treating automation as a substitute for fixing a fundamentally broken process. Automation that replicates a broken manual process at higher speed creates higher-speed broken outcomes. Before committing to an automation deployment, the process must be documented, the data quality must be assessed, and the expected outcome must be defined in measurable terms. Automation amplifies what is already there.
The Hybrid Reality and Decision Framework
Most real insurance technology strategy decisions are hybrid. The claims platform might be bought, the fraud detection layer automated, and the customer portal built. The underwriting workbench might be a bought platform with an AI automation layer on top that handles submission processing and pre-populates the risk scoring fields before the underwriter opens the file. The insurers that manage this complexity well are those that apply a consistent decision framework to each component rather than evaluating the whole capability as a single build, buy, or automate question.
| Option | Best when | Watch out for | Typical timeline |
|---|---|---|---|
| Build | The capability is your core differentiator and no market solution matches your specific requirements | Underestimated complexity, talent retention, ongoing maintenance cost, and time-to-value versus a market platform | 18–36 months to production |
| Buy | A mature market platform exists, the process is not a differentiator, and speed to value matters more than customisation | Vendor lock-in, integration complexity with legacy systems, and configuration limitations that constrain your operating model | 6–14 months to go-live |
| Automate | Your existing system works but the process around it is manual, slow, or inconsistent — and the data quality is sufficient | Treating automation as a substitute for a fundamentally broken process; automation amplifies existing problems as well as strengths | 8–16 weeks to first deployment |
| Hybrid | Different components of the same capability have different build/buy/automate profiles — most real decisions land here | Integration debt accumulating across independently chosen components; governance gaps between vendor-owned and internally owned layers | Varies by component |
For Nordic market insurers, the build, buy, or automate decision carries additional complexity from the integration requirements of Nordic core systems and Finanstilsynet's expectations for third-party technology risk management. Norwegian insurers that buy platforms from international vendors must satisfy Finanstilsynet's requirements for outsourcing risk assessment and ongoing vendor oversight. Specific regulatory interpretations for Norwegian technology investment decisions should be verified with qualified Norwegian legal counsel.[4]
Frequently Asked Questions
We have always built our own systems — why should we consider buying or automating instead?+
The answer depends on whether your proprietary systems are creating competitive advantage or consuming budget that could be invested in differentiated capability. If your development team is spending the majority of its time maintaining and extending systems that any insurer could buy off the shelf, the opportunity cost of building is the innovation investment that is not happening. Build remains the right answer for genuine differentiators. For infrastructure, the question is whether the total cost of ownership of a proprietary system is lower than the equivalent market platform over five years. In most cases it is not.[1][2]
How do we evaluate whether a market platform is the right fit before committing to it?+
The evaluation should cover four areas. Functional fit: what percentage of your requirements does the platform address out of the box, and what will the configuration cost be for the remainder? Integration: how does the platform connect to your existing core systems, and what is the data migration complexity? Vendor stability: what is the vendor's financial position, product roadmap, and reference base of comparable deployments? Total cost of ownership: what are the full five-year costs including implementation, licensing, configuration, and ongoing support? Request references from insurers of comparable size and operating model before shortlisting.[2]
How do we identify which processes are ready for automation?+
An automation-ready process has four characteristics: it is rule-based or pattern-based rather than requiring open-ended professional judgement on every instance; it operates on structured or semi-structured data that can be reliably extracted and processed; it has a measurable outcome that can be used to validate the automation's performance; and the volume justifies the investment — typically at least 500 instances per month for simple automations. Data quality assessment is the prerequisite for any automation deployment. Low-quality input data produces low-quality automated outputs.[3]
What is the right governance structure for a hybrid build, buy, and automate technology portfolio?+
Hybrid technology portfolios require explicit ownership of each component and explicit accountability for integration between them. The most common governance failure is that the bought platform, the automated layer, and the built components each have a clear owner but the integration between them does not. Designate an integration owner for each significant interface between components, define the data contracts between systems formally, and review the integration architecture at each major release cycle. The technical debt that accumulates in poorly governed integration layers is typically harder and more expensive to address than the technical debt in any individual component.[1]
How should we communicate a technology investment recommendation to the board?+
Board presentations on technology investment decisions should answer four questions clearly: what problem does this investment solve in commercial terms; what is the total cost of ownership over five years for each option considered; what is the risk profile of each option including implementation risk; and what does success look like in measurable terms at 12, 24, and 36 months? Avoid technical detail in the board presentation. The board's decision is a capital allocation decision — frame it as one. Include a clear recommendation with a rationale based on the decision framework, not a balanced summary that leaves the choice to the board.[1]
How does the build, buy, or automate decision apply specifically in Nordic market operations?+
Nordic market insurers face additional considerations. Finanstilsynet's outsourcing and third-party risk management requirements apply to bought platforms from international vendors, adding governance overhead to the buy option that is not present in UK deployments. Nordic core systems — particularly legacy policy administration platforms used by Norwegian carriers — have historically been less API-ready than UK equivalents, making the automation option more complex where the underlying system does not expose clean data interfaces. Norwegian-language processing requirements apply to any AI or automation layer that handles customer or broker communications. Specific regulatory requirements should be verified with qualified Norwegian legal counsel.[4]
References
All statistics sourced from documented deployments and third-party research organisations. Links verified 2026. Click any citation to jump to its source.
Every major insurance technology decision comes down to three options: build it, buy a platform, or automate what already exists. Most insurers get this wrong by applying the same answer to every question. This post provides a clear decision framework: when each option creates value, when it creates technical debt, and why most real decisions are hybrid — with automation increasingly winning on speed, cost, and reversibility.
Three Columns. Four Months. One Recommendation by Thursday.
The slide on screen shows three columns. Build. Buy. Automate. The CTO has been working on this decision for four months. The claims management system the insurer has been running on for eleven years is no longer fit for purpose. It cannot support real-time FNOL intake. It does not expose APIs that the digital team needs for the customer portal. It was last updated meaningfully in 2019. The maintenance contract costs £840,000 a year for a system that handles a process the business increasingly cannot do competitively.
Option A: build a proprietary replacement. Estimated cost: £4.2 million. Timeline: 28 months. Risk: high. Option B: buy a market platform. Estimated cost: £2.1 million over three years including implementation. Timeline: 12 months to go-live. Risk: medium. Three vendors have been shortlisted. None is a perfect fit. All require configuration work. Option C: automate and extend the existing system. Estimated cost: £480,000. Timeline: 14 weeks to first workflow. Risk: lower. The process problems get addressed without replacing the system that underlies them.
The board wants a recommendation by Thursday. The CTO knows that whichever option she recommends, she will be accountable for it for the next five years.
Key Figures
| Figure | What it means |
|---|---|
| 68%[1] | Of large insurance technology implementation projects run over budget or over time, with the average overrun on build projects being 40% of the original estimate. Buy projects overrun at a lower rate but with higher average implementation complexity than initially scoped. |
| 60–70%[2] | Of total IT budget at legacy-dependent insurers consumed by maintaining existing systems rather than investing in new capability. This proportion has grown year on year since 2020 as maintenance costs on ageing infrastructure compound. |
| 14 weeks[3] | Average time to first measurable outcome for AI and workflow automation deployments in insurance operations, versus 12 months for bought platform go-lives and 28 months for significant build projects. |
| 3.2×[3] | Average return on AI automation investment in insurance operations over a 24-month deployment period, based on documented deployments across claims, underwriting, and finance functions in UK and European markets. |
| 42%[2] | Of insurers that chose a buy option for a major technology component reported that vendor lock-in and configuration limitations became a material constraint on their operating model within three years of go-live. |
Why Insurance Technology Strategy Decisions Are Harder Than They Look
Insurance technology strategy is the discipline of making technology investment decisions that compound competitive advantage rather than creating the technical debt that slows the next decision. A clear framework does not make the decision for you. It makes the decision-making process consistent, the tradeoffs explicit, and the criteria visible enough to defend in a board meeting and revisit objectively when the outcome is reviewed.
When to Build
The conditions that justify proprietary development
Build is the right answer in a narrow set of conditions: when the capability you are developing is a genuine competitive differentiator, when no market platform exists that addresses your specific requirements at the required scale, and when your organisation has the engineering capability to deliver and maintain the solution through multiple iterations. All three conditions must be true simultaneously. If any one is absent, build is almost certainly the wrong choice.
The competitive differentiator condition is the most frequently misapplied. Insurers regularly conclude that their claims handling process, their underwriting workbench, or their policy administration workflow is a differentiator that justifies proprietary development. In most cases it is not. The capability that differentiates an insurer commercially is the quality of its underwriting judgement, the strength of its distribution relationships, and the speed and fairness of its claims handling. The systems that support those capabilities are infrastructure. Building proprietary infrastructure is expensive, slow, and creates maintenance obligations that persist long after the original development team has moved on.[1]
When to Buy
The conditions that favour a market platform
Buy is the right answer when a mature market platform exists that addresses the capability gap, when the process the platform supports is not a differentiator, and when the speed to value from a bought solution materially outweighs the configuration cost. The most common failure mode in buy decisions is underestimating configuration complexity. A platform that covers 80% of the insurer's requirements out of the box will cover the remaining 20% through configuration — and that configuration work is not free. It requires the insurer's subject matter experts, the vendor's implementation consultants, and the insurer's integration team to work together for months, often in parallel with live operations.
The 42% of insurers who reported vendor lock-in as a material constraint within three years typically encountered it because the configuration required to make the platform fit their operating model created dependencies that made switching prohibitively expensive.[2] Vendor selection should evaluate: the platform's API architecture and integration capabilities; the vendor's product roadmap and its alignment with your three-year requirements; the total cost of ownership including implementation, configuration, licensing, and support; and the references of comparable insurers who have deployed the platform in a similar operating context.
When to Automate
The conditions that make automation the fastest path to value
Insurance IT modernisation does not always require replacing the system that is causing the problem. In many cases, the system is adequate. The process around it is not. Manual data entry, inconsistent decision-making, slow handoffs between teams, and the absence of real-time workflow visibility: these are process problems that AI and workflow automation can address without touching the underlying system.
Automate is the right answer when the underlying system holds clean, structured data that an automation layer can read and write to; when the process problem is one of consistency, speed, or volume rather than fundamental capability; and when the organisation needs measurable outcomes faster than a buy or build timeline allows. The 14-week average time to first outcome for automation deployments, versus 12 months for bought platforms, is the decisive commercial argument in many situations.[3]
The failure mode in automation decisions is treating automation as a substitute for fixing a fundamentally broken process. Automation that replicates a broken manual process at higher speed creates higher-speed broken outcomes. Before committing to an automation deployment, the process must be documented, the data quality must be assessed, and the expected outcome must be defined in measurable terms. Automation amplifies what is already there.
The Hybrid Reality and Decision Framework
Most real insurance technology strategy decisions are hybrid. The claims platform might be bought, the fraud detection layer automated, and the customer portal built. The underwriting workbench might be a bought platform with an AI automation layer on top that handles submission processing and pre-populates the risk scoring fields before the underwriter opens the file. The insurers that manage this complexity well are those that apply a consistent decision framework to each component rather than evaluating the whole capability as a single build, buy, or automate question.
| Option | Best when | Watch out for | Typical timeline |
|---|---|---|---|
| Build | The capability is your core differentiator and no market solution matches your specific requirements | Underestimated complexity, talent retention, ongoing maintenance cost, and time-to-value versus a market platform | 18–36 months to production |
| Buy | A mature market platform exists, the process is not a differentiator, and speed to value matters more than customisation | Vendor lock-in, integration complexity with legacy systems, and configuration limitations that constrain your operating model | 6–14 months to go-live |
| Automate | Your existing system works but the process around it is manual, slow, or inconsistent — and the data quality is sufficient | Treating automation as a substitute for a fundamentally broken process; automation amplifies existing problems as well as strengths | 8–16 weeks to first deployment |
| Hybrid | Different components of the same capability have different build/buy/automate profiles — most real decisions land here | Integration debt accumulating across independently chosen components; governance gaps between vendor-owned and internally owned layers | Varies by component |
For Nordic market insurers, the build, buy, or automate decision carries additional complexity from the integration requirements of Nordic core systems and Finanstilsynet's expectations for third-party technology risk management. Norwegian insurers that buy platforms from international vendors must satisfy Finanstilsynet's requirements for outsourcing risk assessment and ongoing vendor oversight. Specific regulatory interpretations for Norwegian technology investment decisions should be verified with qualified Norwegian legal counsel.[4]
Frequently Asked Questions
We have always built our own systems — why should we consider buying or automating instead?+
The answer depends on whether your proprietary systems are creating competitive advantage or consuming budget that could be invested in differentiated capability. If your development team is spending the majority of its time maintaining and extending systems that any insurer could buy off the shelf, the opportunity cost of building is the innovation investment that is not happening. Build remains the right answer for genuine differentiators. For infrastructure, the question is whether the total cost of ownership of a proprietary system is lower than the equivalent market platform over five years. In most cases it is not.[1][2]
How do we evaluate whether a market platform is the right fit before committing to it?+
The evaluation should cover four areas. Functional fit: what percentage of your requirements does the platform address out of the box, and what will the configuration cost be for the remainder? Integration: how does the platform connect to your existing core systems, and what is the data migration complexity? Vendor stability: what is the vendor's financial position, product roadmap, and reference base of comparable deployments? Total cost of ownership: what are the full five-year costs including implementation, licensing, configuration, and ongoing support? Request references from insurers of comparable size and operating model before shortlisting.[2]
How do we identify which processes are ready for automation?+
An automation-ready process has four characteristics: it is rule-based or pattern-based rather than requiring open-ended professional judgement on every instance; it operates on structured or semi-structured data that can be reliably extracted and processed; it has a measurable outcome that can be used to validate the automation's performance; and the volume justifies the investment — typically at least 500 instances per month for simple automations. Data quality assessment is the prerequisite for any automation deployment. Low-quality input data produces low-quality automated outputs.[3]
What is the right governance structure for a hybrid build, buy, and automate technology portfolio?+
Hybrid technology portfolios require explicit ownership of each component and explicit accountability for integration between them. The most common governance failure is that the bought platform, the automated layer, and the built components each have a clear owner but the integration between them does not. Designate an integration owner for each significant interface between components, define the data contracts between systems formally, and review the integration architecture at each major release cycle. The technical debt that accumulates in poorly governed integration layers is typically harder and more expensive to address than the technical debt in any individual component.[1]
How should we communicate a technology investment recommendation to the board?+
Board presentations on technology investment decisions should answer four questions clearly: what problem does this investment solve in commercial terms; what is the total cost of ownership over five years for each option considered; what is the risk profile of each option including implementation risk; and what does success look like in measurable terms at 12, 24, and 36 months? Avoid technical detail in the board presentation. The board's decision is a capital allocation decision — frame it as one. Include a clear recommendation with a rationale based on the decision framework, not a balanced summary that leaves the choice to the board.[1]
How does the build, buy, or automate decision apply specifically in Nordic market operations?+
Nordic market insurers face additional considerations. Finanstilsynet's outsourcing and third-party risk management requirements apply to bought platforms from international vendors, adding governance overhead to the buy option that is not present in UK deployments. Nordic core systems — particularly legacy policy administration platforms used by Norwegian carriers — have historically been less API-ready than UK equivalents, making the automation option more complex where the underlying system does not expose clean data interfaces. Norwegian-language processing requirements apply to any AI or automation layer that handles customer or broker communications. Specific regulatory requirements should be verified with qualified Norwegian legal counsel.[4]
References
All statistics sourced from documented deployments and third-party research organisations. Links verified 2026. Click any citation to jump to its source.
How insurers are deciding which technology to build, buy or automate