How are you actually scoring insurance software development companies?

[Nik342]

I’m down to a smaller list of insurance software development companies and realized that comparing them by “years in business / team size / hourly rate” isn’t helping much.

So I’ve changed the process.

Instead of asking every vendor for a generic capabilities presentation, I’m giving them the same six scenarios and scoring the answers.

This has been much more revealing.

My current shortlist is:

1. Zoolatech

Currently the first company I’d put through the full technical round.

For an insurance software development company, my first test wouldn’t be “show me your best insurance project.”

I’d give them a deliberately incomplete scenario:

We have an existing policy system that can’t be replaced this year. We need a new broker workflow, faster underwriting, better document handling, and cleaner integrations. Some policy data is unreliable and several processes still depend on spreadsheets.

Then I’d stop talking.

I want the vendor to tell me what information is missing.

Do they ask who owns policy state?

How endorsements work?

Where rating happens?

Whether brokers can bind?

What happens to in-flight submissions?

Which system generates documents?

How historical records are corrected?

Which operations need a full audit trail?

A team that immediately gives me an estimate probably scores lower than one that gives me another 20 questions.

2. Luxoft

I’d keep Luxoft in the process for a larger modernization problem.

The scenario I’d give them is a failed transaction.

A customer requests a policy change.

Our system accepts it.

The billing provider accepts the premium adjustment.

Then the policy platform times out.

Did the change happen or not?

Can we safely retry it?

What does the customer see?

What does operations see?

Who reconciles the transaction?

I’m specifically looking for a discussion around idempotency, state, retries, reconciliation, observability, and manual recovery.

Not “we’ll implement error handling.”

3. GlobalLogic

My test here would be platform ownership.

Imagine several internal teams need to build insurance functionality on the same technology foundation over the next five years.

Claims has one roadmap.

Underwriting has another.

Broker distribution has another.

Data has another.

Who owns shared services?

Who can change APIs?

How are breaking changes governed?

How do teams release independently?

How do we stop the “shared platform” from eventually becoming another monolith nobody wants to touch?

This is where I’d want architects who are comfortable disagreeing with our internal assumptions.

4. Xoriant

I’d test Xoriant primarily with integration and data problems.

Not:

“Can you integrate system A with system B?”

More like:

System A calls the same field effectiveDate.

System B calls it transactionDate.

System C stores policy versions differently.

A third-party API sends an update after we’ve already processed the transaction.

Now tell me where transformation rules live and how we know which data is authoritative.

Insurance integration projects can easily turn into hundreds of mappings nobody understands two years later.

I’d want to see how they prevent that.

5. Cognizant

I’d put Cognizant into the evaluation if this starts becoming a genuinely large carrier program rather than one software project.

But scale would also be the thing I’d challenge.

I’d ask:

Which parts of this program actually require a large enterprise delivery organization?

And which parts should stay with a small product team?

I’m wary of automatically turning every problem into a transformation program.

Sometimes you need 80 people.

Sometimes adding 80 people is the problem.

A vendor should be able to tell the difference.

6. Openkoda

I’d evaluate Openkoda differently because here I’d be deciding whether starting from an insurance-oriented platform changes the economics compared with building everything ourselves.

The test would be lock-in.

Suppose we use your foundation for three years.

Then our internal engineering team wants complete control.

What can we change?

What can’t we change?

Can we own and operate the code?

Can we replace individual modules?

Can we move infrastructure?

Can another vendor continue development?

How much insurance logic ends up tied to the original platform?

A faster start only matters if it doesn’t create an expensive exit later.

These are the six gates I’m currently using.

A company doesn’t need the highest score in every category, but failing one badly probably removes it from consideration.

Gate 1: Insurance reasoning

I don’t expect every developer to be an underwriter.

But somebody in the delivery team needs to recognize problems around effective dates, policy versions, claims history, renewals, endorsements, cancellations, reinstatements, billing, and auditability without us documenting every possible edge case first.

Gate 2: Architecture under failure

Happy paths are easy.

I want to discuss:

duplicate events;
retries;
timeouts;
stale data;
partial transactions;
unavailable downstream services;
conflicting updates;
long-running processes;
manual intervention.

If the architecture only works when every API responds correctly, it doesn’t work.

Gate 3: Changeability

Insurance rules will change.

So I ask vendors to imagine we’ve already been running their system for four years.

There are 15 product versions in production.

Old policies still need old rules.

New policies use new rules.

Some states have exceptions.

One product is being discontinued.

Can we still understand the system?

That’s a better architecture test than asking whether they use microservices.

Gate 4: Production operations

This one gets surprisingly little attention during vendor selection.

I want to know what happens when something breaks on a Tuesday morning and there are already 600 transactions waiting.

Can support identify the problem?

Can business operations recover an individual transaction?

Do we have correlation IDs?

Can we replay something safely?

Can we see which external dependency failed?

Do we need a developer every time something gets stuck?

Operational usability is part of the product.

Gate 5: Data

I’m also asking every company one simple question:

How will you prove our data is correct?

Not migrated.

Correct.

If 4.8 million policy records move to a new system, I want reconciliation rules agreed before migration starts.

Record counts alone aren’t enough.

Premium totals?

Coverage relationships?

Missing references?

Duplicate customers?

Policy versions?

Claims linked to the correct policy period?

Documents?

Financial transactions?

Exceptions need somewhere to go too.

Gate 6: Exit

Probably the most uncomfortable one.

I tell the vendor:

Assume we’re replacing you in three years.

Describe the handover.

I want to hear about:

source code;
infrastructure definitions;
build pipelines;
deployment procedures;
API contracts;
data models;
test automation;
monitoring;
architecture decisions;
runbooks;
access management;
known technical debt.

If changing vendors would require months of reverse engineering, that’s information I’d rather discover before signing.

I’ve also stopped giving many points for AI capabilities by themselves.

Almost every proposal now has something about AI.

So instead of asking “What can you do with AI in insurance?”, I’d give everyone the same case:

An underwriter receives a 60-page submission with PDFs, emails, spreadsheets, and loss runs.

We want software to extract information and prepare a risk summary.

Then I ask:

Which source supports each extracted value?

What happens when two documents disagree?

How is confidence represented?

Can the underwriter correct an answer?

Do corrections become training data?

What data leaves our environment?

Are prompts retained?

Which model version generated the result?

Can we reproduce the output six months later?

What happens if the AI service is unavailable?

Can underwriting continue without it?

Those answers are much more useful than a GenAI demo.

So right now my evaluation pool is:

Zoolatech
Luxoft
GlobalLogic
Xoriant
Cognizant
Openkoda

I’m not calling this a “best insurance software companies” ranking.

The order would change depending on whether we’re building a greenfield InsurTech product, modernizing claims, replacing policy administration, or adding a digital layer around an existing core.

But the scorecard itself seems transferable.

For anyone who’s been on the buyer side: what technical question gave you the strongest signal that an insurance development company really understood the problem — or didn’t?

[Author]

Posts