What Five Years With a Fortune 500 Insurance Client Actually Teaches You

In 2020, most insurance companies were buying time.

Legacy systems kept running. Transformation roadmaps sat in slide decks. The word "insurtech" was something you mentioned to sound forward-thinking at conferences.

Then a few things happened pretty quickly.

In Q3 2025 alone, 21 insurtechs were acquired - the most in three years. Including Munich Re's $2.6 billion purchase of NEXT Insurance, completed in Q3 2025. This is one of the largest insurtech P&C acquisitions to date, which is hard to ignore. 

The AI hype started. 82% of insurers believe AI will define the industry's future — but only 14% have actually integrated it into their operations.

And then there are big transformation programmes from the last decade. Years of work. Real money spent. And because so many were never quite finished, a lot of carriers ended up running the old systems alongside the new ones. More cost, complexity, and margins that quietly took the hit.

Nobody gets those calls perfectly right. This stuff is genuinely hard.

We didn't have all the answers either. But in 2021, we got a call from a large specialty insurer — US, UK, Nordic operations — and we showed up. Andrey Zhilitsky, our Delivery Director, flew in with a team of four.

That was five years ago. The account now has 186 specialists. And the people who built it are still here.

The SVP that we visited onsite in 2026 said: "You've gone from a vendor to part of the team."

The number that explains everything: ~2.2 years

The average tenure across our 186-person account team is roughly 2.2 years. For our UK team specifically, it's 2.5. 

This sounds unremarkable until you compare it to the alternative. Most staff-augmentation vendors rotate resources every 6–12 months — sometimes by design, because new placements generate new fees, and sometimes because the best engineers leave when they get bored. Either way, the client absorbs the cost: time spent re-onboarding, context lost in transitions, velocity that never quite recovers.

One of our client's AVPs described what this looks like in practice: "Other vendors rotate resources after 6–12 months. I have not noticed that with Symfa at all."

The model: we don't sell headcount

The phrase we use internally is "we don't sell headcount" — which sounds like marketing until you see what it means in practice.

When a team joins a client engagement, they bring Business Analysis, Engineering, and QA together as a single unit. Requirements, delivery, and quality ownership live in one place. The client doesn't need to coordinate between a BA firm, a dev shop, and a QA contractor — the team handles the whole thing, from first user story to production release.

11× growth. Our BA headcount on this engagement grew eleven-fold. Not because we were selling BA services, but because the client's delivery got better when requirements had someone responsible for them from the start.

This matters more as projects get complicated. When an underwriting rules engine has 1,214 rules that need to be migrated into a single auditable system, and rule changes need to go from "weeks" to "five minutes" — you need people who understand the business logic, not just the code. That's a BA problem as much as an engineering problem.

One story worth knowing

In 2023, the client's claims management platform was processing end-to-end in 3–5 days. Claims adjusters were spending roughly 2.5 hours of manual effort per claim. The system worked, but it wasn't fast enough for where the business was going.

Our team rebuilt it. Post-launch: end-to-end processing dropped to 1–2 days — roughly 60% faster. Adjuster effort per claim fell by about 2.5 hours. Platform usage went up 57%. More than 90% of users agreed the new system was easier to use.

None of that happened because we wrote good code. It happened because we had engineers who'd been on the account long enough to understand the claims workflow, BAs who could translate adjuster pain into requirements, and QA engineers who knew what "done" actually meant for this client.

That's what tenure buys you. Not loyalty — comprehension.

How this partnership actually started

I want to be honest about something: the first version of this engagement looked a lot like staff augmentation.

The client needed engineers with specific skills. We had them. We placed them. For a while, that was the relationship — professional, productive, and limited.

What changed it was time. The engineers who joined in 2021 are still here. They became the people who knew where the bodies were buried in a monolithic codebase that had grown over a decade. They became the people client engineers asked questions to, not just the people who took tickets. The client's team leads stopped treating them as contractors and started treating them as colleagues.

By the time the business started asking harder questions — can you help us modernise this platform? can you add automation to this workflow? can you build something that uses AI? — we already had teams capable of answering those questions, because they'd spent years understanding the systems those questions were about.

This transition doesn't happen by accident. It requires a deliberate decision, early, to optimise for continuity over cost. Most clients don't make that decision explicitly — it tends to happen, or not happen, based on how the first year or two goes.

Growing the skills as the problems evolved

One of the things I'm most proud of — and this is the thing I don't think shows up in pitch decks — is how the team's skills have evolved to match the client's needs, rather than the other way around.

When the client's data infrastructure needed to move from on-premise to the cloud, engineers on the account didn't just wait to be replaced. They got Azure-certified. The client organised an in-house bootcamp — practical pipeline work, not just theory — and our engineers were part of it. That's a detail that matters: when a client invests in upskilling your team alongside their own, it means they've stopped thinking of you as a vendor.

When the client needed to modernise a core commercial platform — decomposing a monolith, migrating to Kubernetes-based zero-downtime deployments, consolidating APIs — the same engineers who'd built features on the old system became the people capable of rebuilding it responsibly. You can't buy that kind of institutional context. You have to earn it through years of showing up.

When AI tooling became relevant — GitHub Copilot, Claude Code, LLM-assisted test generation — our teams didn't wait for a mandate. The tech lead on the International BI & ETL Platform team noted that Symfa engineers were among the first to adopt Copilot when it was rolled out across their team. One engineer was singled out unprompted as "kind of extraordinary" for combining ETL and .NET expertise — the cross-functional profile the team had been deliberately building toward.

~40–50% faster coding. ~50–70% less time on test authoring. These are the measured results from our AI-in-development practice — not from a single tool deployment, but from a disciplined rollout with human review maintained throughout.

The point is not that we adopted AI tools. Everyone is adopting AI tools. The point is that we adopted them on production systems, with insurance clients, in a regulated environment, and the results are measurable and verifiable — not theoretical.

What the data shows: four case studies

Claims Management Platform. End-to-end processing: 3–5 days → 1–2 days. Adjuster effort: ~2.5 hours per claim saved. Sessions post-launch: +57%. User satisfaction: >90% agreed usability improved.

Analytics and Management Platform. Report generation: ~400% faster. Database footprint: 7 TB → 300 GB — a 95% reduction, at equal workload coverage. This a structural change in how data is managed.

Underwriting Rules Engine. 1,214 rules unified into a single auditable source of truth. Rule change time: weeks → ~5 minutes. Processing time: 77 milliseconds. Audit history: 100%. Developers required to change a rule: zero. That last number is the one that matters most — it means the business can change underwriting logic without engineering involvement. That's a relationship between IT and business that most insurers spend years trying to achieve.

Agentic AI. This is the most recent project, and the one that generates the most questions. The problem: every endorsement request was moving through underwriters by hand. An agent submitted a request by email; an underwriter read it, validated policy data, logged into the system, made changes, sent back a PDF. Roughly ten manual handoffs per endorsement.

The AI agent reads the same inboxes. It classifies the request, validates policy data, and calls the same APIs the underwriter would use. On the happy path — when data is clean and complete — the endorsement is processed and returned to the agent without a human touching it. When data is incomplete, the workflow halts and creates a task in the underwriter's Daybook with the original email attached.

No silent failures. Every event logged. Clean escalation when needed. The design is responsible: full automation where it's safe, human judgment where it's not.

About ten manual handoffs reduced to exceptions-only handling.

The R&D question

When we visited the client's London office in May 2026, the Head of IT Development told us he hadn't known Symfa had an R&D unit until that meeting. His reaction was immediate: he framed it as an opportunity to "throw real problems at Symfa and see what comes back."

That reaction tells you something about where the partnership had gotten to — and also about what was still being left on the table.

Our R&D unit has been working on insurance-specific AI problems for several years. Not hypothetically. The claims-intake PoC is a useful example. The client processes roughly 107,000 claims per year, with about 30 FTEs reading emails and routing intake manually.

The pipeline we built: email ingestion, OCR and LLM extraction, classification by claim type, confidence scoring, human-in-the-loop review for low-confidence cases, downstream API integration. What it produces: structured, source-referenced claim data ready for processing — 24 hours a day, without a human reading every email.

$1M net annual savings. 333% Year-1 ROI. 3.6-month break-even on a ~$300K investment. Intake team: 30 → 10 FTEs. Speed per claim: ~10× faster.

These are modelled projections from the PoC, not live production figures — that distinction matters, and I won't pretend otherwise. But the model is grounded in the client's actual cost structure, and the pipeline exists and works. The question now is deployment timeline, not feasibility.

The R&D unit also has live PoCs for explainable ML — pricing models and fraud risk profiles where every decision comes with a SHAP-attributed explanation and an LLM-generated narrative. The reason this matters in insurance is straightforward: business teams won't adopt AI they can't explain to a regulator or a senior leader. Explainability isn't a nice-to-have; it's the thing that determines whether the model actually gets used.

The honest trade-offs

I want to name two things that don't always make it into the pitch.

The first is requirements clarity. The consistent feedback from engineers embedded on this account — unprompted, in their own words — is that requirements can be inconsistent across streams. This is normal in large enterprise insurance environments; distributed ownership and legacy processes produce exactly this pattern. Our embedded BA model addresses it at the team level, and AI-assisted requirements tooling is reducing the cost of late clarification. But I won't pretend it doesn't exist, because it does, and pretending otherwise wouldn't serve anyone.

The second is legacy infrastructure. VDI performance, monolith decomposition timelines, the sheer weight of a system that's been running insurance operations for a decade — these things slow things down sometimes. Another tech lead put it plainly: the team has been together three to five years, they know the architecture completely, "there is no rocket science." The flip side is that getting to that state required years of working in the legacy system, not around it.

I'd rather acknowledge these things and explain how we manage them than have you discover them six months into a partnership.

What the client's VP actually said

The moment that meant the most to me from our May 2026 London visit wasn't a case study or a metric.

It was when the VP, Head of IT, asked us — unprompted, in the middle of a conversation about their 2026–2027 roadmap — what Symfa is seeing in the market. Not what we could do for them. What we see. What trends we're tracking, what we'd recommend, what we'd do in his position.

That's not a vendor conversation. Vendors get asked about capacity and pricing. Partners get asked for perspective.

We've been working toward that kind of conversation for five years. It's the only kind worth having.

If you're evaluating engineering partners for an insurance technology program, here's what I'd look at — and what I'd push on if I were sitting on the other side of the table:

Ask for tenure by account, not by company. A firm with low overall attrition can still rotate engineers off your account every 12 months. Those are different things. Ask specifically: what is the average tenure of engineers on your longest-running accounts?

Ask how requirements ownership works. If a partner separates BA, engineering, and QA — if requirements "belong" to a different team than the one writing code — you'll be paying for the coordination overhead yourself. Ask who owns the full delivery cycle, and what happens when a requirement turns out to be wrong.

Ask for AI-in-development metrics from real projects. Not "we use Copilot." Not "we've deployed LLMs." Specific numbers: what share of test automation, what baseline, what review process. If they can't answer that, they haven't actually built the practice.

Ask what their R&D unit has shipped. Not what it's working on — what it's shipped. Finished PoCs, production deployments, ROI calculations. The firms with real applied AI capability have artifacts to show. The firms that are catching up to the market have slide decks.

And ask yourself this: when you imagine a senior person from this firm sitting in a room with your leadership team five years from now — are they the kind of people you'd want to ask for their perspective on a hard problem? Or are they the kind of people who give you what you ask for and wait for the next request?

Both are useful. Only one of them future-proofs your business.

I wrote this article because I've spent five years watching what good partnership looks like from the inside, and I think it's worth describing honestly — not just celebrating.

The things I'm proudest of are not the metrics, though the metrics are real. They're the individual engineers who joined this account as mid-level developers and became the people who redesign architecture. The BA team that grew eleven-fold because the client's delivery got better when requirements had a real owner. The team lead who told us in London, without prompting, that Symfa engineers are "some of the most knowledgeable people we've got."

That kind of outcome requires time, consistency, and a deliberate choice to build something durable rather than something scalable.

If that's the kind of partnership you're looking for — or if you're not sure yet, but you're willing to think about it — I'd like to have that conversation.