How We Built a Claims System That 2,500 Adjusters Use Every Day

Before I get into how it went, let me explain what we were actually solving.

The Client processes over 100,000 workers' compensation claims per year through its US claims division. The adjusters who handle those claims — the people who interview injured workers, interview employers, reconcile conflicting accounts, calculate benefits — were doing all of that work through a system that had been running for years past its natural lifespan. The interface was painful. Making any change to it was painful. Finding developers who still wanted to work with those technologies was getting harder every year.

The business had finally committed to fixing it. Not patching. Not bolting on features. Rebuilding on a modern stack, module by module, until adjusters had one place to work instead of three.

That became Claims Modernization. And that became us.

I want to be honest about how this project started, because I think it matters.

When we kicked off, the team was ready. Motivated, capable, experienced — a group of engineers that wanted to build something. The problem was that the requirements weren't ready to match them. The client knew what outcomes they needed but pinning down the specifics took time. For a long stretch in the early phase, we were doing more research and discussion than actual implementation. Figma mockups would appear, we'd start building toward them, they'd change. Again. And again.

The real challenge that period wasn't technical. It was people. How do you keep a team of 22 engineers fired up when the pace of actual delivery is slow? When the work they're ready to do keeps waiting on decisions they're not in a position to make?

You find the work you can move forward. You give people pieces that are genuinely theirs. You don't pretend the situation is more exciting than it is — engineers can tell. You just keep the flame from going out.

Looking back, that slow period was also when we were making the architecture decisions that everything else would depend on. Those decisions aged well. But that's not how it felt at the time.

Two technical decisions shaped this project more than anything else.

Blazor over Angular. This was a real debate inside the team. Developers had strong opinions based on their own experience. The argument that won was simple: every developer on our team was a .NET engineer. Blazor is a C# framework. The cognitive lift to get everyone productive would be minimal compared to Angular, which would have meant a significant context switch.

The trade-off was honest: Blazor is newer. The community is smaller. When you hit a problem that Stack Overflow hasn't seen yet, you're on your own. That happened. We solved it. If I had to make the call again, I'd make it the same way.

Micro-frontends over a monolith. This was the client's proposal, and I think it was the right one for the scale we were eventually going to reach. The application had grown complex enough that a single codebase with five teams working inside it would have turned into a coordination nightmare. Five independent deployable modules composing into one application gave each team real ownership.

The cost: synchronization. If Team 3 needs a contract that Team 1 hasn't shipped yet, releases block. We built a process around that — Scrum of Scrums, weekly dependency checks, explicit interface contracts between modules. We've been running bi-weekly production releases since March 2025. Not one has been missed. The architecture made that possible.

Here's the part of the story I think about most.

The project had a production release date: March 31, 2025. We knew it for a long time. But the reality is that requirements came in slowly through most of 2024. Work was happening — we were building — but not at the pace a March deadline ultimately required. Then, starting around September or October, things accelerated. More requirements. More scope clarity. More to do.

By January, we were three months from go-live with a scope that assumed we'd been running at full pace the whole time.

I remember thinking: this is exactly like a student who coasts through an entire semester and then tries to learn everything in the last month before exams. And I was that student's teacher, watching it happen, knowing I couldn't fully prevent it.

What I could control was what happened next. The team doubled down. We were running five parallel squads, each owning their module, each with their own release cadence. At the end of every sprint, we had a staging release on Monday night and a production release Thursday night — a window of maybe three days to catch problems, fix them, and get everything clean before it went live. That is not a comfortable amount of time.

People stayed later than they should have. Some nights the Argentina half of the team — we had engineers across time zones, Poland and Georgia on one side, Argentina on the other — picked up the thread when our side had to log off. That distributed time-zone structure that can feel like a complication turned out to be an asset in those final months. When Polish engineers were done for the evening, Argentina was just getting started.

We shipped on March 31. Not everything made the cut — one feature got deferred as a fast-follow. But nothing was cancelled. The date didn't move. And every bi-weekly release since then has gone out on schedule.

I want to explain what the platform does, because it's easy to lose the human picture inside the technical description.

An adjuster handling a workers' compensation claim is doing something that looks deceptively simple: interviewing people and writing reports. In practice, it's highly structured investigative work. They interview the injured worker. They interview the employer. They interview other parties. They compare what everyone said. They flag contradictions. They calculate what the injured person is owed, down to the daily rate, accounting for every employer they had in the 52 weeks before the incident.

Before this platform, a lot of that work lived on paper — or across four separate applications that didn't talk to each other. A notebook for interview notes. A legacy system for claim data. A task manager for routing. And a benefit calculation process that someone was doing by hand, spreadsheet by spreadsheet, raise by raise.

The platform collapses that into one place. Claims land ready to work. Interviews are structured in real time — role-specific question sets, automatically captured. When the claimant's account of events contradicts the employer's, the reconciliation engine surfaces the conflict immediately and puts it in front of the adjuster to resolve. That decision becomes the source of truth for everything downstream.

Benefit calculations — tracking every employer, every wage period, every retroactive raise, producing a legally correct daily compensation rate — are now structured, traceable, and auditable. There are many places where data about a claimant can live, and it can contradict itself. The platform is where you make the call that everything else defers to.

Early in the project, I had what I thought was a good idea.

Adjusters conduct dozens of interviews. Interviews follow structured question sets. Couldn't we use AI to make those calls? Automate the intake, collect the answers, hand the adjuster a completed record?

The client explained to me why that wouldn't work.

Adjusters aren't just collecting answers. They're detecting deception. They notice hesitation. They hear the difference between someone who's uncertain and someone who's evasive. They catch contradictions not just between what one party says and another, but between what someone says and how they say it. A script cannot do any of that. Replacing the adjuster with automation would make the output worse — and in workers' comp claims, worse can mean paying fraudulent claims or denying legitimate ones.

That conversation became something more than a no to a feature suggestion. It became the design principle for the entire platform: humans make judgment calls, technology handles everything else. The reconciliation engine flags conflicts; the adjuster resolves them. The benefit engine handles arithmetic; the BA validates inputs. We support the work, we don't replace it.

I think that principle is the reason 93% of users report the platform is helpful to their daily work. We built for how adjusters actually think, not how a system designer would imagine they think.

In March 2026, we had a different kind of AI conversation.

Upstream from the adjusters, there's an intake team that handles the first part of every claim: emails arrive 24/7 with PDF attachments, forms, notices. Someone has to parse those, validate the information against policy data, enter everything manually into the system, and route it forward. When the intake team comes in every morning, there's a queue waiting for them — claims that came in overnight, sorted by nobody.

I knew this part of the workflow. And I thought I could see a solution.

I proposed building a POC using OCR and an LLM to process those incoming emails automatically. Our initiative. Not client-requested. We scoped it, built it, and showed it to the AVP who runs the intake team.

The application works like this: emails arrive, attachments are processed, every field in the claim form is extracted and presented alongside the original document. Each field gets a confidence score. Fields below 80% are highlighted for human review. Clicking any field in the review panel highlights its exact location in the source PDF so the reviewer can verify in seconds rather than minutes.

The goal isn't to make decisions. It's to clear the backlog. The intake team shouldn't have to arrive every morning and start from zero. The system does the overnight work; the human reviews and approves.

When I explained this to the client, the response was genuine interest. Not yet in production, but moving.

What I'm most proud of isn't the technology. It's that we identified the problem ourselves, because we'd spent enough time in this domain to see it. That's not what a vendor does. That's what a partner does.

I want to be direct about something.

When this project started, I had never managed a team of 25 people split across five sub-teams. I'd managed projects, I'd managed teams — but not at this scale, with this kind of coordination requirement. I had to figure out Scrum of Scrums as we went. I had to build a layer of team leads who could report upward so I wasn't in every meeting at once. I had to learn what it means to make a commitment to one stakeholder out of a hundred competing requests, and actually keep it.

I interviewed and hired most of the people on this team. That's a strange kind of relationship — you've looked someone in the eye across a hiring call, you've made a judgment, you've told them you believe they can do this. When it works, it's not just a professional outcome. It's a personal one.

The team we built delivered. Zero missed releases. 2,500 daily users. The kind of numbers that mean the work was real.

The platform today covers the core adjustment workflow. Claims come in, adjusters work them, reconciled reports route out. That's the middle of the claims lifecycle — and it's a big, functioning, well-adopted middle.

But intake is upstream. Supervisory review is downstream. The longer arc is one unified system: from the moment a claim notification arrives to the moment a supervisor signs off. The AI POC is one step toward connecting the upstream. The agentic framework work — AI agents handling endorsement requests and policy changes for the underwriting team — is another signal of where this is all pointing.

I don't know how long that full unification takes. This engagement is already past two years and it shows no sign of ending. That's not a complaint. Complex problems at scale don't resolve quickly, and the right response isn't to rush toward a finish line that keeps moving.

Two thousand, five hundred people. Every morning. Opening something we built.

The road ahead looks like more of the same.

We publish engineering stories from real projects — no sanitized case studies, no vendor-speak. If that's useful to you, follow Symfa on LinkedIn or come back for the next one. More on insurance modernization, API-led architecture, and what embedded delivery actually looks like in the related articles below.

Follow Dmitry on LinkedIn for more backstage stories about insurance modernization projects.