Insurance Software Development: An Honest Guide

You will not find an insurance software failure that can be put down to a bad choice of framework. The trouble is when a team puts the tools in hand before they have accounted for every regulator, filed rate and business rule that applies to the product. We saw it with a Central European carrier where such an oversight became an eight-year policy administration exercise and a $500 million write-off. A Southern European claims platform ran 500% over budget for the same reason. There was no shortage of engineers on either side; what was missing was a complete view of the system under replacement.

In many ways this sets insurance software apart from the rest of the industry. It is regulated financial infrastructure, not some app you can put together. An auditor, a reinsurer or a state regulator must be able to reconstruct every claim settlement, underwriting call and rating change. Cloud has become the standard way to deliver new systems and AI is the favourite investment, yet BCG figures indicate only 4 per cent of insurers have managed to scale AI across their claims operations. Most are still running pilots. That is the chasm between what vendors will tell you and the operating reality, and where budgets go to die.

The purpose of this guide is to help insurtech teams, MGA operators and insurance leaders determine how to sequence their work and whether to build or buy, without ending up as another cautionary tale.

Should You Build Insurance Software At All

There is a desire for a straight answer: build, buy or configure. But the decision itself is less important than the groundwork laid beforehand. Look at any high-profile failure and you will see a pattern of multi-year big-bang replacements with poor governance and little legacy discovery. Successes are the inverse: narrow in scope, delivered in phases and with an eye on the business rules.

So forget about what to build for a moment. The question is what you really know about the system and product you have today.

Start with the business shape, not the feature list

An MGA rolling out a specialty line and an insurtech putting coverage into a third-party product have little in common with a carrier looking to modernise a 22-year-old policy admin system, even if the screens appear alike. The economics are entirely different.

Speed of deployment tells the story. According to one survey of insurance executives, 65 per cent of companies require three to six months to design and deploy a new product, 33 per cent need up to a year. Only 1 per cent do it in under three months. That is the baseline for working with existing infrastructure. If a vendor is touting enterprise software in under half a year, he is likely leaving out the integration or regulatory filings.

Where custom build earns its keep

Custom development is only sensible when the software is the business model. You might have a niche underwriting workflow that off-the-shelf options cannot handle, or a distinctive customer journey. Or perhaps your legacy environment would make any vendor tool a burden for future changes. Absent those conditions, configuration is the better first move.

The best examples of modernisation are hybrids. Take Aviva, which did not rebuild its core but instead put an API-first architecture and 80-plus AI models in front of it to realise £60 million in savings in 2024. “We are serious so we will customise” is the wrong approach. A disciplined team will run a product discovery process to distinguish where custom code makes a difference and where it is merely added maintenance.

The Four Modules Every Insurance Product Depends On

Be it an embedded travel policy or a homeowner carrier, there are four moving parts to every product. Let one get weak and you lose money or trust.

Policy administration is the source of truth

Then there is policy administration (PAS). This is where the system knows who is covered and on what terms. Endorsements, renewals and cancellations are all recorded here. Teams tend to underestimate it because it presents as a form on the surface. Underneath you have product hierarchies, rating variations and the need to back-date changes without muddying the audit trail. Do not open an editor until you have put in the time on the functional requirements.

Underwriting decides what you will write

Underwriting is the risk desk. In a well-configured system a rules engine sits between intake and binding to decide on price and exclusions. When the regulations shift, that engine is rewritten. Hard-coding is a shortcut that will be paid for at every filing update.

Billing and claims are where the promise gets tested

Billing takes care of the premiums and commission accounting. Claims is where the brand is put to the test. One mid-size P&C carrier reworked its claims module and in 36 weeks saw a 94 per cent ROI in the first year. They cut loss adjustment expense by 23 per cent and brought the cycle time down from 14 days to 5.2, with straight-through processing up to 78 per cent. It is often the place to start with modernisation.

The Tech Stack Question Is Smaller Than You Think

Technology leaders and founders like to argue over the stack – Node or Java, monolith or microservices. But the stack is rarely what undoes an insurance project. It is the complexity of the product configuration, data quality and the integration surface area.

Cloud-native is the default, but not the goal

Some 84 per cent of new system purchases are cloud-based these days. It is table stakes. For most carriers, a wholesale cut-over is simply not an option. The architectural question that really matters is how the new system will live alongside the old one. You have core systems with decades of policy history, treaty obligations and regulatory reporting on their books; they are not going to be put on hold for a rewrite.

What we see time and again in modernization that works is the strangler fig pattern. Put an API in front of the legacy system, leave it running, and then peel away its functionality in slices. One national life insurer with 380,000 policies and $2.1 billion in premium did exactly that to retire a 22-year-old PAS over an 18-month period. There was no frozen roadmap or dramatic cutover involved. We go into the details of this in our legacy software modernization guide.

Integrations are where projects slow down

Insurance products do not exist in a vacuum. To have a stack that functions you need CRM, e-signature, document generation, payments, identity verification, reinsurance reporting and perhaps telematics or third-party risk data. A mid-tier P&C carrier will have 14 to 22 such systems, all unconnected. About 40% of your project cost will be found in the integration, migration and post-launch work. It is hardly a frontend issue.

Our rule of thumb is to ship a real product with the fewest integrations possible. Each additional connector is a versioning headache, a testing surface and a potential weak point in the audit trail.

Multi-tenant matters if you sell to multiple brands or regions

Then there are the structural choices for an MGA, TPA or insurtech platform: tenant isolation, per-tenant configuration, data residency. These are far easier to design in at the outset than to bolt on once you are live. When more than one brand or jurisdiction is in play, make sure to consult the multi-tenant architecture guide before locking in a design.

Regulation Is Not a Review Step. It Is the Architecture.

Do not think of compliance as something legal puts a stamp on when the job is done. It should inform your data model, deployment pipeline and logging from day one. Teams that put it off as a formality find themselves paying for it in market conduct exams and rework.

The constraints can pile up fast. In the U.S. you have the NAIC Model Audit Rule, the AI Model Bulletin for underwriting and pricing, NYDFS Part 500, NIPR licensing, the MCAS and, where relevant, HIPAA or PCI-DSS. Over in Europe it is Solvency II, GDPR, IAIS reporting and EIOPA priorities. At a technical level they are all after the same thing: continuous evidence and lineage on the data, not a year-end scramble to reconstruct decisions.

That has some bearing on how you build:

• Underwriting and pricing must be replayable, with inputs and model versions intact.
• If a product is misconfigured and rating does not map to filed rates, you will face restitution.
• AI requires governance out of the gate – interpretability, bias monitoring, versioning. Do not add it later.
• Make cybersecurity and evidence logging part of the CI/CD, not a quarterly report.

An honest Vanta review can tell you what automation is actually doing for you if SOC 2 is in the cards, and where you still need to put in engineering hours.

MVP Scope That Actually Survives Insurance

Most teams overestimate what an insurance MVP should be. A realistic one is narrow: a single line of business and distribution channel with a quote-to-claim path that is safe to put in front of a customer. Anything beyond that is scope creep.

Take an MGA putting out a specialty commercial line. They require a lean intake, underwriting rules for the segment, basic billing and FNOL with human routing, and enough admin to keep the ops team out of spreadsheets. Leave the complex payment plans and full claims automation for down the road. We follow that discipline in any MVP development process: be hard on the scope and ship the one path that counts.

A workable first-release feature map

Module	Ship in MVP	Defer
Policy administration	Quote intake, bind, renewal basics, endorsements	Deep workflow customization, multi-product hierarchies
Underwriting	Rules-based decisions, clear referral path to human review	ML pricing models, external data enrichment
Billing	Invoice generation, payment status, refunds, basic commissions	Complex installment plans, broker statements at scale
Claims	FNOL intake, status tracking, manual routing	Straight-through processing, fraud models, image AI
Governance	Audit log, versioned decisions, access control	Full model governance dashboards

Team shape matters more than headcount

You do not need a large staff for an MVP but you cannot afford to be without the right people. There has to be a product lead to guard the scope, a domain expert from underwriting or claims to spot the regulatory edge cases, a designer who can make the workflow sensible to an adjuster, and QA capable of building scenario matrices by state and timing. And one or two engineers who can get things done. Some may be part-time but none are optional.

We have taken on that shape for clients ourselves. With the Workform AI MVP build, the original idea was an “AI assistant for everything.” Discovery whittled it down to a focused product that pulled from the user’s existing tools and was shippable. Insurance is best served by the same approach.

Build vs Buy by Company Type

Generic advice has a way of being unhelpful when different operators have different needs.

Small and mid-size carriers with legacy stacks. Buy or configure first. Only write custom modules where the gap in the legacy system is material and painful. A complete rebuild is rarely the way to start.

MGAs with a new specialty line. Go hybrid. Let the vendor handle the standard PAS machinery and put in your own code for the workflow that is truly unique. Unless the niche workflow is the product itself, a custom-only solution is seldom warranted.

When it comes to insurtech startups and embedded insurance, the approach is API-first with an emphasis on integration. One has only to look at the insurtechs that have not made it to see the error of putting a pretty UI over legacy underwriting that has not been altered; the loss ratios are invariably worse than what the incumbents can put on the table. The ones that are still around after three years have learned to work within carrier workflows instead of trying to supplant them.

For TPAs and reinsurers, the customer-facing side of the UI is less important than having the right data platform and reporting infrastructure. That is where you find the leverage, in treaty reporting and data mesh patterns.

We apply a straightforward filter:

• If it is standard workflow at volume, buy or configure it.
• Build for the niche product logic that sets you apart.
• Where engineering capacity is limited but speed is needed, buy first and extend down the road.
• A hybrid model for any unique distribution or embedded experience.

Our build vs buy for founders guide offers a more thorough diagnostic on this trade-off.

Realistic Costs, Timelines, and Governance

People will want to know the cost before anything else, even if scope should take precedence. An MVP for one line of business will typically set you back between $150,000 and $400,000 for a 4 to 9 month build. Put in a full platform with several lines and the requisite compliance workstreams and you are looking at 12 to 24 months. Take the mid-size P&C claims platform we mentioned as an example: 36 weeks to deliver, running some $680,000 in development with another $120,000 for first-year infrastructure and optimization. Consider those planning figures rather than hard promises.

Variables that will affect the bottom line include the state of the systems you are integrating with, the depth of your regulatory jurisdictions, and how much of the product is custom as opposed to configuration. It also depends on whether legacy discovery is part of the project or has been done already, and on the team’s discipline with respect to MVP scope.

Governance is where projects live or die

There is a pattern to the failures we have seen: fixed-price agreements with no milestone gates or independent quarterly review, and no board-level mechanism to hit the brakes when a project is 15% over budget or 20% behind schedule. The successful cases are the reverse, with reset triggers and third-party reviews baked into the contract from day one.

Questions worth asking any partner

Some questions to put to a potential partner:

• Who on your side is responsible for NAIC AI Bulletin obligations and state filings? How have you dealt with that in the past?
• Give me an example of how you would proceed if you ran into undocumented rules in a legacy system.
• I would like to see an artifact from a prior engagement to see what your discovery phase turns up.
• What does month 13 look like once you hand off the system?
• How do you go about structuring your milestones and pause triggers?

If there is any hedging in the answers, move on. This is not an industry where you should be learning at your client’s expense.

Where the Real Risk Lives

The technology is rarely the reason an insurance software project goes south. More often it is because someone did not give enough weight to legacy business logic, made an afterthought of compliance, or put out features the agents would not touch. The teams that get results put in the hours on the unglamorous stuff: mapping out the rules in a senior underwriter’s head, getting the filed rates right, and designing a workflow an adjuster will actually use.

A good partner will be able to talk you through that before giving you a quote. For the early decision work required to get things in order before development begins, Refact’s product design and discovery is meant to handle exactly that.