Skip to content
Lincoln Labs
Past engagement

A policy system built in the early 2000s

Start a conversationAll past engagements
Platform rebuildClient not named
Where it is now

Mid build, with the team scaling as scope firms up. The legacy system retires after launch rather than before it.

What they had

A policy administration platform that turned every ordinary change into a development project. Launching a program, entering a new state, adding a form: each one queued behind engineering. The system did not just fail to help the business grow, it set the pace at which growth was allowed to happen.

What we did

One nine month engagement rather than a series of phased contracts, with discovery folded in as the opening stage instead of sold separately. More than a dozen functional areas are in scope, covering the full lifecycle from intake and underwriting through pricing, issuance, billing, claims and regulatory reporting.

The team is built as one group with two sides: a named senior launch team, and a dedicated delivery team hired and employed through our talent engine. Pricing is flat and monthly for the full window, with no per item charges, which removes the incentive to argue about every request.

Kickoff and discovery open the window. Build runs module by module from there, with user acceptance testing before launch and the legacy system winding down after it rather than before.

Why this shape

Why this shape fit them.

An insurer cannot stop writing policies while its policy system is replaced. The work has to happen alongside a business that is still running, in a domain where requirements are set by regulators and vary by state, which means scope keeps surfacing no matter how carefully it was written down at the start.

An itemized contract in that environment produces a change order almost every week, and after a few months the relationship becomes a negotiation rather than a build. A flat monthly fee for a fixed window removes the incentive entirely. When something new surfaces in month four, and it will, the answer is that it goes in the backlog. Nobody has to price it, argue about it, or decide whether raising it is worth the friction.

Folding discovery into the opening phase rather than selling it separately works for the same reason. In a replacement project the real scope is not knowable until somebody is inside the legacy system, so charging for a discovery phase first only delays the point at which useful work starts.

The two sided team is a cost decision on their behalf. Senior people who have replaced insurance platforms before are expensive and are needed most at the start. A dedicated delivery team carries the volume across the nine months. Keeping both in one engagement means they pay senior rates for senior judgment and not for the hours where it is not required.

This engagement is written up without naming the client. Product specifics and anything that would narrow the sector to one company are left out. The situation, the structure and the reasoning are what matter to somebody in the same position.

The other engagements

Four more shapes.

Different constraints, different structures.

Pricing automationThousands of bid files, priced by handRead itMarketplace buildA launch date already on the calendarRead itTeam buildSoftware, and a team to run itRead itFeasibilityTesting whether the idea was possibleRead it
Start a conversation

Is this close to your situation?

We will tell you which shape fits.

Start a conversationSoftware development