The Missing Point in the Buy vs. Build Debate

In insurance technology, the buy vs. build decision is usually framed as a cost comparison: what an internal build costs against what a vendor platform costs. That framing answers the smaller question. The larger question is what happens after the build ships, because an AI system is not a fixed asset that depreciates on a schedule, it is a continuing obligation to keep pace with a technology curve the organization does not control. 

Key Operational Takeaways: The Buy vs. Build Debate 

• Insurance operations consume 12 to 14 points of combined ratio for carriers and roughly half of total margin for brokers, before any AI decision is made. 
• Insurers, brokers, and MGAs face three realistic paths: build internally, wait for a frontier lab to produce something insurance-compatible, or deploy an insurance-native platform. 
• An internal AI build is not a project with an end date; it is a continuing obligation to keep pace with a technology curve the organization does not control. 
• The processing layer beneath is common to every organization in the market, which is why “owning it” has never differentiated any of them. 
• An internal build is not just competing against other internal builds; it is competing against years of accumulated R&D, and against models that already know the nomenclature of insurance: the coverages, wordings, exposures, and classes a new build has to learn from scratch. 

What is the Buy vs. Build Debate? 

In most industries, internal builds carry a familiar cost: maintenance, periodic upgrades, and gradual depreciation. AI is different. The pace of advancement is unlike previous technology cycles, and the gap between what an internal team can sustain and what the external market produces is widening, not narrowing. The industry has a term for what accumulates when technology investments fall behind the pace of change: tech debt. In AI, that debt accrues faster than most organizations expect, because the underlying technology is moving faster than any internal team can reasonably match. 

That is the argument that the buy vs. build debate tends to skip. Not whether you can build. Whether you want to own the obligation of keeping up, and keeping in mind the progress that you are losing while building. 

The Build Cost that Already Exists 

Operations are already consuming significant margin. For a typical carrier, the processing layer accounts for 12 to 14 points of combined ratio. For brokers, back-office workflows absorb roughly half of total margin. That drag exists whether an organization builds, buys, or does nothing at all. 

The question is what AI investment does to that number. 

As mea Platform’s CEO, Martin Henley, argued in Intelligent Insurer, “If you’re competing on the back office, you’re not getting it right.” The processing layer is not where competitive advantage lives. Underwriting judgment, risk selection, client relationships, and portfolio construction are. The back office should be as efficient as possible so that capital and talent can flow toward those differentiators. 

That observation is where the buy vs. build question gets more interesting. 

The 3 Buy vs. Build Paths 

Most organizations considering AI for insurance operations face three realistic options: build it internally, adopt a general-purpose AI platform from a frontier lab and configure it for insurance, or deploy a purpose-built insurance-native platform from a vendor. Each carries different cost structures, risks, and trade-offs. 

1) Build it yourself 

Most internal builds follow a recognizable pattern; organizations spend 9-18 months assembling a team, sourcing data, building integrations, training models, and configuring workflows. Some produce useful results, but many stall: research suggests that 70 to 80% of complex digital programs fail to reach their stated goals, and 88% of business transformations fall short of their intended ambitions. 

But the harder truth applies even when the build succeeds. AI systems are not software you install, configure once, and depreciate over a standard cycle. New models emerge, integrations change as tools rise/fall, and compliance and governance requirements evolve. Workflow logic needs continuous refinement.  

Every organization that builds internally becomes the permanent owner of a system that requires continuous adaptation against an exponential technology curve it does not control. The cost shows up initially, but rises drastically later: in engineering headcount, in delayed capability upgrades, in the slow accumulation of “tech debt” as the gap between what you built and what the market now offers widens quarter by quarter. 

2) Wait for a frontier lab 

A growing number of organizations are quietly waiting for LLM providers and hyper-scalers to build something insurance-compatible. The logic is understandable: if the largest AI companies are investing billions into model capability, why not wait for that capability to reach insurance? 

The risk is structural dependency. When you build your operating layer on top of a single general-purpose model, your workflows are downstream of an organization whose priorities, roadmap, and pricing have nothing to do with insurance. If that provider deprecates a model version, adjusts its API, or raises prices, your operations absorb the impact with limited recourse. You are subject to their pricing structure, their product decisions, and their support model. 

That support model matters. General-purpose AI providers serve thousands of industries simultaneously. Insurance is one use case among many. When a submission triage workflow breaks or a claims routing logic needs refinement, you are not speaking to someone with decades of underwriting experience. You are filing a support ticket with an organization that does not have domain expertise in how (re)insurance operates. 

3) Deploy an insurance-native platform 

The third option is to deploy a platform that was built specifically for insurance operations from the ground up: a domain-specific language model℠ trained on insurance, an insurance knowledge graph℠ shaped by underwriters and claims professionals, and years of real transaction volume informing every workflow. 

A platform like mea integrates with leading LLMs rather than being locked to one. That means the system adapts as the broader AI landscape evolves, incorporating new models and capabilities without requiring the client to rebuild. The insurance-specific intelligence sits in the knowledge graph℠; the general capability connects through whichever model best serves the task. As the AI landscape advances, the platform grows with your workflows rather than forcing your workflows to conform to a single provider’s architecture. 

Why Control in Insurance AI Does Not Equal Advantage 

The instinct to build internally comes from a desire for control: control over data, over workflow configuration, over the technology stack; in many domains, that instinct is sound. 

In AI infrastructure for insurance operations, it often works against the organization. 

The processing layer that sits beneath underwriting, claims, finance, and broking is not a source of competitive differentiation. Every insurer, reinsurer, and broker needs submissions ingested, data validated, documents classified, workflows routed, and exceptions flagged. The mechanics are remarkably similar across organizations, even where products, appetites, and markets differ. 

When internal teams spend their time building and maintaining commodity infrastructure, that means engineering capacity, leadership attention, and capital is not being directed toward the work that differentiates the business. Failure rates on large technology programs are high, not because the technology is impossible. They are high because the project itself becomes the story, consuming organizational energy that was meant to go elsewhere. 

As Graeme Asquith, mea Platform’s UK Managing Director, put it: “There are cross-industry problems that can be solved once in a productized way. You want to know that problem is handled and move your brainpower to the next opportunity.” 

Frequently Asked Questions About the Buy vs. Build Debate in Insurance AI 

Should insurers build or buy AI for insurance operations?  Build where the capability differentiates you, and buy where it does not. The processing layer beneath your talent is common to every carrier and broker, which makes it the clearest case for buying: competing on the back office spends scarce engineering capacity on work no client ever chose you for. mea deploys as that layer across underwriting, claims, finance, and broking, so internal teams keep their capacity for the work that does differentiate. 

What is the real cost of building insurance AI in-house? The upfront figure is the smaller half. The 9 to 18 months of development are not neutral time; competitors who deployed are already compounding operational gains while you are still assembling. The target also moves during the build, so a system that was current at kickoff tends to need work before it has processed anything. From there the durable cost begins: continuous model updates, integration maintenance, and governance changes, all measured against a technology curve the organization does not control. The posture ends up closer to catching up than setting the pace. And the organizations you are measuring against are not funding that R&D themselves; their platform absorbs it, which keeps them moving with the curve rather than toward it. 

How should the buy vs. build decision be measured? By the same standard as any operational investment: what it does to the expense ratio and/or margin, and how quickly. Project milestones, systems delivered, and completed pilots measure activity rather than result, which is how a build can look successful and still fail to move margin. The measures that matter are cost per completed transaction, elapsed turnaround time, straight-through completion rate, and combined ratio impact. If a build cannot be assessed against those within a defined window, the decision is being judged on effort rather than outcome. Read our full KPI list in our KPI whitepaper.

The Operational Insight: The Buy vs. Build Debate 

Regardless of which path an organization takes, these three things remain true: 

• The drag is already there, before a single AI decision is made 
• Building internally has no end date
• The processing layer is common to everyone, and owning it has never differentiated anyone 

Organizations that started building 12 months ago are competing against platforms that have spent years refining AI systems against real insurance transactions at scale: working alongside underwriters, training models, and building infrastructure that only produces results after sustained volume. An internal build team working from a standing start is not 9 to 18 months behind on a timeline. It is building against a moving target while its competitors compound growth and market share. And the target accelerates. 

At mea, we process over $200 billion GWP in annual transactions across carriers, reinsurers, MGAs, and brokers globally. Every one of those transactions refines the domain-specific language model℠ (dsLM) and deepens the insurance knowledge graph℠ that allow our agents to operate on live, high stakes insurance-work at an unparalleled level of accuracy and efficiency. That is the part an internal build cannot replicate at any budget: the accumulated volume of real insurance work the system has already learned from, and every transaction processed makes the gap continuously larger. 

That is the missing point in the buy vs. build debate. The question was never whether you can build, it is whether you want to own an indefinite obligation to travel against an exponentially moving AI curve in a domain that will never differentiate you. 

AI agents own the repeatable. People own the consequential.