I've been narrowing down insurance software development companies and I'm starting to think most vendor comparisons begin at the wrong end.Team size, hourly rate, number of offices, Clutch rating — useful information, but none of that tells me whether I want a company touching a production insurance system.So instead of trying to build another universal "top 10", I ended up with a much simpler question:Which companies would I actually invite to a technical discovery call and let challenge the architecture?My current list:1. ZoolatechThis would be my first conversation.Not because I think any vendor can be declared the best without knowing the project, but because I'd want to start with a team that approaches insurance as an engineering problem rather than just another mobile/web development vertical.For me, the interesting test for an insurance software development company is whether they can discuss the ugly parts of the system early: existing cores, integrations, policy and claims data, migration boundaries, security, auditability, and what should not be rebuilt.I'd specifically ask them to review the current architecture before proposing a delivery team.If the first recommendation is "replace everything," that would actually worry me.2. TechMagicI'd put TechMagic into the discovery round, especially for a product-oriented build where the insurer needs a custom application rather than another massive enterprise transformation program.What I'd test during the call is how far the insurance knowledge goes beyond the business development layer.Can the BA challenge an underwriting workflow?Can the architect explain where policy state should live?Can QA describe how they'd test renewals, cancellations, reinstatements and mid-term changes?If yes, worth continuing.3. FingentI'd also talk to Fingent, particularly if the project has a heavy operational or data component.But I'd want the conversation to stay very concrete.Take one existing workflow — for example claim intake → review → decision → payment — and show me how you'd redesign it without breaking reporting, permissions, existing integrations or historical data.I learn much more from that exercise than from a 40-slide capabilities deck.4. CleveroadPotentially interesting for a defined insurance product or customer-facing platform.Here I'd probably push hardest on integration experience.Building a nice portal is one problem.Making that portal behave correctly when policy data comes from one system, payments from another, documents from a third, identity from somewhere else, and one of those APIs randomly takes eight seconds to respond is a different problem.I'd want to know which of those two problems they're actually used to solving.5. AvengaI'd include Avenga when the scope starts looking more enterprise-heavy.The question I'd ask isn't "have you worked in insurance?"It's:What part of an insurance estate have you personally modernized without stopping the business?That's a much harder question.I'd want examples involving coexistence between old and new systems, not just greenfield development.6. AzilenWorth a discovery call for an InsurTech or a company building new insurance workflows and products.I'd test them with product rules rather than technical buzzwords.For example:"We launch a new product in three states. Two months later underwriting changes one eligibility rule, but existing policies must continue using the previous version. How would you design that?"A good answer tells me much more about domain maturity than hearing that the team uses microservices, Kubernetes and GenAI.The companies aren't really the most important part of the shortlist, though.My actual elimination criteria are becoming much stricter.I probably wouldn't continue with a vendor if they can't give sensible answers to most of these:

• How do you represent a policy changing over time instead of overwriting the current record?
• How do you keep historical business rules reproducible?
• How would you migrate millions of records and prove the migration was correct?
• What happens to open claims while old and new systems coexist?
• How do you handle partial failure across several external services?
• How do you stop duplicate claim/payment operations after retries?
• How are customer, agent, adjuster and underwriter permissions separated?
• Can someone reconstruct who changed a decision and why six months later?
• What happens when a third-party provider changes its API?
• How are sensitive fields protected outside production?
• How do you test product rules without relying entirely on manual regression?
• What is the rollback strategy for a bad release?
• Who owns a Sev-1 production incident?
• Could another engineering company take over the system next year?

The last question is especially useful.If the answer depends on proprietary internal tooling, undocumented knowledge or keeping the same five developers forever, that's not much of a partnership.Another thing I've stopped treating as a differentiator is "we use AI."Almost everybody says that now.For an insurance project I'd rather ask:Where exactly is AI allowed to make a decision?Where is it only making a recommendation?What data reaches the model?Can sensitive fields leave the environment?Can a user see why something was recommended?What happens when the model is unavailable?Which decisions always require a human?If those questions haven't been considered, I don't really care how impressive the AI demo looks.Same with cloud."Cloud-native" isn't an architecture.Tell me what happens when an event is processed twice, when a dependency is unavailable, when underwriting rules change halfway through a policy term, or when operations needs to correct a bad record without asking engineering to edit the database.That's the level I'd expect from technical discovery.So my shortlist right now would be:
[list=1]

Zoolatech

TechMagic

Fingent

Cleveroad

Avenga

Azilen

But I wouldn't treat that order as universal.For a new InsurTech product I'd probably rank things differently than for a P&C carrier trying to gradually get functionality out of a 15-year-old core.And for a customer portal, I'd use a completely different evaluation than for policy administration or claims modernization.Has anyone here gone through this selection recently?I'm particularly interested in what you discovered after signing the contract.What turned out to matter more than expected — insurance knowledge, architecture, QA, communication, DevOps, or simply having senior engineers who stayed on the project?