I'm comparing insurance software development companies for a P&C project and would be interested in feedback from people who've gone through something similar.

The situation isn't a full core replacement.

The existing policy administration system will probably stay for another few years. What needs to change around it is:

• claims intake and workflow;
• broker self-service;
• underwriting rules;
• document processing;
• integrations with external data providers;
• reporting;
• some fairly painful manual operations.

There is also a lot of historical policy and claims data that we don't want to move unless there's a good reason.

That distinction has made vendor research much more difficult than I expected.

A lot of companies look suitable when the requirement is simply "insurance software development." Once I change the question to "Can this team modernize part of an insurance estate without turning it into a core replacement?", the shortlist gets much smaller.

These are the companies I'd currently put through the first technical round.

1. Zoolatech

Zoolatech would be my first call, mainly because I'd want to see how they approach the modernization boundary before discussing a development estimate.

For this project, the ideal insurance software development company shouldn't automatically recommend rebuilding everything.

I'd give them the current architecture and ask:

What should still be running exactly as it is two years from now?

That's not a trick question.

If the PAS is stable at policy issuance but terrible at exposing data to brokers, perhaps the answer isn't a new PAS. Maybe it's an API/integration layer and a new broker experience.

If claims has one problematic stage, perhaps we replace that workflow rather than the entire claims system.

What I'd want to hear is a sensible decomposition of the problem.

I'd also want their architects, not only sales or account people, in that discussion.

2. Andersen

I'd include Andersen in the technical evaluation but probably give them a different test.

I'd provide a policy-change workflow with several dependencies:

customer requests an endorsement → eligibility is checked → premium changes → approval may be required → documents are regenerated → billing is updated → broker is notified.

Then I'd ask what happens when billing succeeds but document generation fails.

Or the customer submits the request twice.

Or an external service times out but actually processes the request.

Those situations tell you very quickly whether a team is designing an insurance workflow or just connecting APIs.

3. Coderio

I'd include Coderio if the project starts leaning more toward engineering capacity plus modernization rather than a completely outsourced product.

My concern with this delivery model would be ownership.

Who is responsible for understanding the insurance domain?

If our product owner has to define every edge case before engineers can build anything, we're basically buying development capacity.

That's sometimes perfectly fine.

But for this project I'd prefer engineers and analysts who eventually start identifying missing scenarios themselves.

For example:

"Should this endorsement affect an already reported loss?"

"Which policy version applies?"

"What happens if the effective date is retroactive?"

Those questions are valuable.

4. SoftTeco

I'd probably evaluate SoftTeco around claims and policy workflows.

The practical test I'd use here would be data lineage.

Take one claim.

Can we reconstruct:

• which policy version was active on the loss date;
• what information the customer originally submitted;
• which fields were changed later;
• who changed them;
• which rules were applied;
• which external data was used;
• why the claim moved to the next state?

If the proposed design mostly stores the latest state of everything, I'd have concerns.

Insurance systems have long memories.

Something that looks irrelevant today may need to be explained during a complaint, audit, litigation, or internal review much later.

5. Stratoflow

I'd consider Stratoflow if performance and more complicated backend engineering become a significant part of the scope.

But again I'd want to test the actual architecture rather than generic scalability claims.

I'd ask something like:

Suppose renewal season creates a large spike in quoting activity while document generation, pricing, and several third-party services are under load.

Which operations need to happen immediately?

Which can be asynchronous?

What happens when a downstream service is temporarily unavailable?

What gets retried?

What must never be processed twice?

How does an operations person know that something is stuck?

"Scalable architecture" means very little until those questions have answers.

6. RaftLabs

I'd potentially include RaftLabs for a smaller or more product-focused part of the program.

For example, if we separated broker self-service or FNOL into its own initiative instead of giving one vendor the entire modernization roadmap.

The main thing I'd verify is project scale.

There is a big difference between building an insurance application and gradually changing workflows used across an established carrier.

Neither is necessarily harder in every respect, but the operational risk is different.

The company list is only part of the exercise.

I've also started building a technical checklist that every vendor gets before we discuss price.

Some of the questions are deliberately uncomfortable.

Policy lifecycle

How do you represent a policy that changes several times during the year?

Do you mutate one record or preserve effective-dated versions?

If a claim is reported today for an accident six months ago, how do you determine which coverages and limits apply?

Claims

Can the same claim action safely be submitted twice?

How are reserves and payments audited?

How do you deal with a workflow that is partially completed when an external service fails?

Can operations manually correct a situation without directly editing a production database?

Integrations

What happens if an external API takes 30 seconds instead of two?

What happens if it returns a success response but we lose the response?

How are retries handled?

How do we prevent duplicates?

How are breaking API changes detected?

Data migration

How do you prove that migrated data matches the source?

I don't want "the migration script completed successfully."

I'd expect reconciliation at several levels: counts, relationships, financial values, exceptions, and potentially sampling by business users.

And I'd want an explicit answer for records that don't migrate cleanly.

Security

Can production PII appear in test environments?

Who can see policyholder documents?

Can support engineers access customer records?

How is privileged access recorded?

How quickly can access be revoked?

Auditability

Can we reconstruct an important business decision later?

That includes automated decisions.

If a rule or model changes six months from now, can we still explain what logic was used for a decision made today?

Operations

What does a failed transaction look like to a business user?

A generic "Something went wrong" message isn't enough for an internal insurance platform.

I'd like operations to know whether the problem is:

missing information,

a business-rule rejection,

an integration outage,

a permission issue,

or something genuinely technical.

Release process

How do you deploy a change to underwriting logic?

Can rules and application code be released independently?

What does rollback mean if the release already changed data?

How do you test renewals and endorsements across older policy versions?

Disaster recovery

What's actually included in the recovery plan?

Application servers are usually the easy part.

I'm more interested in data, documents, message queues, integration state, credentials, and transactions that were in progress during the failure.

Vendor exit

This one is going into the contract discussion.

If we stop working together after two years, what exactly exists outside the vendor's heads?

Architecture documentation?

Infrastructure as code?

API definitions?

Runbooks?

Test suites?

Database documentation?

Monitoring configuration?

Deployment procedures?

Decision records?

Could a competent replacement team operate the platform without keeping the original engineers around indefinitely?

I also wouldn't make AI a separate reason to select one of these companies.

We have potential use cases for document classification, claim-file summarization, extracting information from submissions, and helping underwriters review cases.

But I'd rather evaluate those as individual workflows.

For example, if an LLM summarizes a claim file, I'd ask:

Can the adjuster trace every important statement back to the source document?

What happens if documents contain conflicting information?

Is sensitive data sent to an external model provider?

Are prompts and outputs retained?

Can the feature be disabled without breaking the claims process?

What happens when the model service isn't available?

That's more useful to me than "Do you have GenAI experience?"

So my current list for the first round is:

1. Zoolatech
2. Andersen
3. Coderio
4. SoftTeco
5. Stratoflow
6. RaftLabs

I don't consider that a general ranking.

Change the project to a greenfield InsurTech startup and I'd probably change the list.

Change it to a complete PAS replacement and I'd change it again.

But for an established insurer trying to modernize around an existing core without creating a five-year transformation project, this is roughly where I'd start.

Would be interested to hear from anyone who's done this from the buyer side.

What requirement or technical question eliminated the most vendors from your shortlist?