How I Took a Stalled AI Insurance Platform to MVP and Cut Document Analysis from 3+ Months to Near Real-Time

When I joined this project, it had a promising idea, a real budget and paying insurance clients waiting for it. What it didn't have was technical direction. The work had been running for a while without anyone owning the architecture, and you could see it in the code. Features were half finished, the frontend used four different styling systems, and there was very little test coverage.

The product was an AI accelerator for group benefits insurance. Insurers and their advisors deal with large, dense documents: plan booklets, policy contracts, renewal packages. Reviewing them by hand is slow, and the analysis this platform was meant to speed up was taking more than three months.

I stepped in as the de facto technical lead. My job was simple to describe and hard to do: get a working MVP shipped without starting over.

Where things stood

Before changing anything, I spent the first stretch listening. I sat with the product team and with the insurance advisory stakeholders to separate two kinds of requirements that had been blurred together:

• Functional: what the document workflow actually had to do. Which documents come in, what has to be pulled out of them, who reviews the results, and what happens next.
• Non-functional: how fast processing had to be, how sensitive client data had to be protected, and how to keep each insurer's data separate from the others (multi-tenant isolation).

That second list mattered more than anyone expected. In insurance, a feature that works but leaks one client's data into another client's view isn't a feature. It's an incident.

The decision log

Here are the calls I made, in roughly the order I made them, with the reasoning and the trade-off for each.

Decision 1: Use Azure AI Document Intelligence with configurable extraction schemas

The call: Instead of building custom extraction logic for each document type, we used Azure AI Document Intelligence and defined configurable schemas for what to extract.

Why: Insurance documents vary a lot between carriers, but the information people need from them is fairly consistent. Configurable schemas meant a new document type became a configuration task, not a development project.

The trade-off: We were tied more closely to one cloud provider's AI service. For a product already running on Azure, with clients who expected that, it was the right trade.

Decision 2: Upgrade Angular from v17 to v20 and adopt Signals, now

The call: Pay down the frontend's performance debt early instead of living with it.

Why: Upgrades only get more expensive as a codebase grows. Doing it while the app was still MVP-sized was the cheapest it would ever be. Angular Signals also gave us simpler, faster state handling in the screens that showed live processing status.

The trade-off: A few weeks where some effort went into the platform rather than visible features. I explained that to stakeholders up front so it didn't look like the team had gone quiet.

Decision 3: Consolidate four styling systems into one

The call: The frontend had SASS, Bootstrap, an old version of Tailwind and Material UI, all at once. I moved everything onto a single Tailwind v4 design system.

Why: Every new screen started with the question "which system do we use here?", and the answer was different every time. One system removed that question.

The result: About 25% less development time on new components.

Decision 4: Make processing status visible to everyone

The call: I designed the Spring Boot REST API on Azure Cosmos DB with role-based access control, document versioning, and real-time processing status built in.

Why: When document analysis took months, nobody expected to see progress. Once it got fast, people wanted to see it happening. Status visibility built trust with stakeholders faster than any demo.

Decision 5: Write the standards down

The call: Development standards and pull request review guidelines, written and shared.

Why: Honestly, partly because I was tired of explaining the same things in every code review. But it paid off. New developers went from about two weeks of ramp-up to two or three days.

Decision 6: Make tests the gate, not an afterthought

The call: I built more than 120 API test cases and more than 1,000 UI tests, and made them part of the CI/CD pipeline in Azure DevOps. Code that broke them didn't ship.

Why: There was very little coverage when I took over. With an AI pipeline, a schema change, or a small library upgrade, things can break quietly. The test suite turned "I think it works" into "we know it works."

The results

The MVP shipped. More importantly, it shipped on a foundation the team could keep building on, instead of one they'd need to rewrite once real clients arrived.

"Thanks for your fantastic tech leadership in building the AI Accelerator for Group Benefits... You are a great team player who takes time to understand the business outcomes, partners with both business and engineering teams to help define the right solution, and are able to balance 'quick' while minimizing near-term refactoring."

Sara Ardiel, Partner and Senior Strategy Advisor

What I'd tell another team in the same spot

A stalled project rarely needs a rewrite. It needs decisions. Most of what changed here wasn't heroic code. It was someone making the calls that had been left open, explaining why, and writing them down.

Separate the functional and non-functional requirements early. In regulated industries like insurance, the non-functional ones (security, data isolation, auditability) are often the ones that decide whether you can launch at all.

AI is the easy part to demo and the hard part to trust. The extraction model got attention, but the role-based access, versioning, status tracking and tests are what made it safe to put in front of real insurers.

If your AI or document-processing project has lost momentum, I'm happy to take a look and tell you honestly what I'd do first.