When we first turned our engineering focus toward insurance, we thought we understood the pitfalls. We were wrong. Insurance isn’t just standard software with extra forms.

A rating engine has to withstand real regulatory scrutiny. A claims workflow needs to be robust enough to withstand scrutiny in court if necessary. Bugs in underwriting rules are especially tricky because they can go unnoticed for a year before causing serious problems.

What caught us off guard back then was how rarely a procurement decision comes down to who gives the best demo. Instead, it comes down to who has actually survived the messy edge cases of daily insurance operations—mid-term endorsements, reinstatements after a lapse, subrogation, and bordereaux reporting that never quite fits the spec.

Having sat on both sides of the table—both as the vendor being evaluated and as the advisor helping carriers evaluate others—we’ve developed a clear view of what separates a good InsurTech partnership from a painful one. This is that view, written the way we wish someone had laid it out for us years ago.

Insurance software isn’t like other software

We aren’t saying this to sound dramatic. It’s a reality that shifts almost every decision you make later.

For starters, regulations are a moving target. Code that works fine in one state or country often needs a complete rewrite, not just a localised tweak, to pass in another. On top of that, the cost of a mistake is out of proportion. A bug in a shopping app is an annoyance; a bug in a claims system during a major storm means real people aren’t getting money they desperately need.

Legacy systems in insurance are critical. They might be very, very old, but they still process real money while you add or build new tools around them. The data is just as complex, containing sensitive health and financial records subject to strict privacy laws. But to be honest, you don’t necessarily need a partner who only works in insurance. Someone with a background in banking or healthcare can offer useful insights. However, check their understanding of the nuances and realities of insurance well.

Know what you’re actually hiring for

Before we let a client evaluate anyone, we push them and ourselves to be specific about what kind of engagement this is.

A greenfield build benefits from product thinking and quick execution. Legacy modernisation, on the other hand, needs patience, a step-by-step replacement plan, and the ability to work within old constraints. Integration projects are different from both. They depend on strong API design, not just a good-looking user interface.

An ongoing managed relationship is more like hiring than simply choosing a vendor. You are expanding your team, not just ordering a finished product. Whether you choose on-site engineering or strike a balance between offshoring and nearshoring, getting honest about team structure before signing saves months of friction.

We’ve watched good partners fail on the wrong project—not because they were bad, but because their actual strength (say, fast greenfield builds) got applied to a job that needed a legacy migration specialist’s patience instead. Get honest about which of these you’re actually hiring for before you start comparing vendors. It saves everyone months.

Understanding the business and goals before jumping into coding

Does your provider build domain context first, or do they simply show up asking which ticket to pick up first?

A reliable software partner starts with discovery. They guide you through domain discovery and event storming to align the software with your true business goals before writing a single line of code. They don’t just “resolve tickets”; their product engineers focus on shipping value end-to-end. They talk about products, user context, and business outcomes rather than just managing billable hours or “talking resources.”

What real domain expertise sounds like

The best sign of real domain experience is not in a pitch deck. It shows in the questions a partner asks before you even think to ask them.

A team that’s actually built in insurance will bring up your treatment of mid-term policy modifications before you do. They’ll ask how you handle reinstatements after a lapse, whether your claims process needs subrogation support, and which lines of business and regulatory agencies you’re filing under.

When you evaluate a partner to build or modernise insurance software, pay attention to how they respond when you ask about a past project that went wrong and how they handled it. We know from experience that every real insurance project faces challenges, such as an undocumented core platform API, a sudden regulatory change during development, or unexpected data quality issues. If a vendor claims they have never had issues, they probably haven’t worked on enough real-world systems. Or they are not being completely honest.

Technical delivery, feedback loops, and real predictability

Understanding the business is only half the job. If a team knows insurance well but has poor engineering habits, they might fully understand your problem but still build something unstable.

Pay close attention to how a partner measures performance and progress:

• True Predictability over “Finger-in-the-Air” Estimates: Ask how your partner proves predictability. A mature team tracks their own real performance metrics and relies on data-driven forecasting rather than guessing.
• Working Software over Abstract Metrics: Watch out for teams that rely solely on traditional agile metrics, such as story-point velocity, without demonstrating tangible progress. Real progress means working, usable software.
• Release Frequency: Ask how often changes are deployed to production. Is it monthly, weekly, daily, or multiple times an hour? High-performing engineering teams ship safely and frequently.
• Fast Feedback Loops: As a business stakeholder and sponsor, are you an active, continuous part of the development process? Or does development happen in a black box where “magic” supposedly occurs in a vacuum? You need tight feedback loops to ensure the final product hits the business target.

In modern software delivery, you should also consider how they use GenAI tooling throughout the Software Development Life Cycle (SDLC). There is no magic trick to moving fast today without leveraging AI tools to improve efficiency and effectiveness. But the hard part is using them wisely. Check whether your provider uses AI intentionally to drive verifiable business results, or whether AI is leading the provider toward random, unverified outcomes.

Beyond delivery mechanics, insurtech platforms live or die by the quality of their integrations. A good partner must speak about architecture in concrete terms. Insurance software never sits in isolation; it is dropped into a crowded, messy ecosystem of legacy policy admin systems, payment gateways, MVR and CLUE databases, document generators, and credit bureaus.

Ask how they test deeply conditional underwriting logic—code that often fails without a loud error. Demand a documented secure development lifecycle, default encryption everywhere, and a current SOC 2 Type II or ISO 27001 certification.

If AI is used for insurance-specific tasks such as risk assessment, valuation, or claims processing, always insist on detailed explanations. For example, we would ask the vendor how they test for proxy variables that could lead to unfair decisions—something we explored deeply when unmasking bias in insurance logic. Or how they monitor the model after launch to ensure it adapts to market conditions, along with customer data changing over time.

The people matter as much as the pitch

The most polished people at a company usually handle sales conversations. The team who will actually write your code and answer your questions six months later is often different. In insurance, where particular knowledge is often held by just a few senior people, it’s important to close that gap before you sign a contract.

Ask for the names and roles of the delivery team. Ask about staff turnover. Request a working session with the real team instead of another sales call. A 60- to 90-minute technical discussion about a real problem from your project will tell you more about fit than three polished presentations.

We’d add one more thing that is not so obvious: ask how a partner handles disagreement. In a regulated industry, you want a partner who’ll say “this creates a compliance risk” or “this will generate more calls to your service centre,” not one who silently builds exactly what’s in the spec even when they see a problem coming.

What five years in insurance software business taught us

After five years in this field, we learned that demos and low bids do not predict how a partnership will turn out. What really matters is honesty. We would ask if the vendor mentions edge cases before you do. Can they talk openly about a past project that went wrong and what they learned from it? We would also ask about security and AI compliance. The answer should not just be a list of general rules or boilerplate responses that could apply to any industry.

How to actually evaluate a potential insurtech software vendor

Domain & business understanding

• They guide domain discovery (e.g., event storming) to build business context before asking which coding tasks to grab first.
• They independently raise complex edge cases such as endorsements, reinstatements, subrogation, and bordereaux reporting.
• Their past work matches your actual line of business and operating regions—not just a vague “financial services” umbrella.
• Their team includes people who understand insurance operations and act as end-to-end product engineers rather than “ticket-resolving resources.”

Technical & process capability

• Predictability: They use historical team performance data and quantitative forecasting rather than arbitrary estimates.
• Progress tracking: They track delivered working software rather than relying solely on story points or abstract velocity metrics.
• Deployment frequency: They deploy to production frequently (daily or multiple times a day) rather than being locked into slow, high-risk monthly releases.
• Feedback loops: They keep business stakeholders continuously engaged rather than building in an isolated vacuum.
• Pragmatic AI use: They leverage GenAI throughout the SDLC to deliver concrete efficiency gains, with controls in place to prevent unpredictable outcomes.
• Integrations & logic: They have a clear plan for API design, legacy integration, and testing complex, conditional underwriting logic so rules don’t break silently.

Security, compliance, and data guardrails

• Security processes are documented, with encryption on by default and a current SOC 2 Type II or ISO 27001 report you can inspect.
• They understand sector-specific rules—such as fair pricing, market conduct, and record retention—rather than merely repeating “we take compliance seriously.”
• If AI touches risk, pricing, or claims, they can explain how decisions are audited, tested for proxy bias, and monitored for performance drift post-launch.

Team and process

• You know the specific engineers assigned to build your project, not just the sales team who pitched it.
• You hold a hands-on technical working session with the actual delivery team before signing anything.
• They are open about team turnover and how they protect project context if someone leaves.
• Handover documentation, architecture blueprints, and training are explicit contractual deliverables.

Commercials and terms

• Contract pricing aligns with the project’s actual unknowns.
• You own the IP and raw data outright, with a clear path to export everything if you part ways.
• Liability and indemnity terms cover security breaches and compliance failures.
• Exit and handover terms are written down upfront, before anyone is under pressure.

Red flags to watch for

• Task-first mentality: They ask for a backlog of tickets to execute before understanding your business domain or end goals.
• Resource talk: They treat engineers as interchangeable hourly headcount rather than as product owners who ship end-to-end value.
• Vague predictability: They offer “finger-in-the-air” estimates without performance data or clear forecasting methods.
• Black-box delivery: They isolate stakeholders and claim progress based on story points while working software remains unseen.
• Uncontrolled AI use: They brag about using AI without showing how they govern its outputs or verify quality.
• Flawless track record: The vendor claims they’ve never had a project experience delays or technical issues.
• Sales-only access: Hesitation to introduce or run a joint problem-solving session with the engineers actually doing the work.