Reinsurance underwriting platform: prototype to production in six weeks

The problem

The client had a clickable prototype. It showed underwriters what the product should do, and none of how it would do it: no backend, no database, no infrastructure.

The platform had to take in submissions, extract the data from their documents, run the underwriting rules, produce a quote and keep an audit history of every decision. It had to run inside the client’s private Azure network, reachable only through a locked-down virtual desktop, and it had to be something the client’s own team could take over.

What OES did

For the first two months OES was the only engineer on the project, so the structural calls were made early, before anyone could argue about them later: one repository with a web app, a background worker and separate packages for the rules, the database and the domain types; which part of the code owns which data; and what a coding agent is and isn’t allowed to touch. Coding agents did a lot of the build. The speed came from settling those questions first and making the codebase enforce them.

Rules in their own package. Every underwriting rule went into its own package: limits, layers and checks. The app asks the rules what’s allowed. It doesn’t contain them. For a product with one client and a short deadline, that looked like extra structure at the time.

Built for real data. Real submissions don’t look like demo data. A typical one listed a couple of dozen locations, and the largest nearly 14,000. Pages load a summary first and fetch the detail when someone needs it, and long lists are paginated on the server. The generated quote was extended to match the client’s own quote package.

Checks that outlast the engineer. An architecture document gets read once, so the boundaries became checks that fail the build when code lands in the wrong place, and say where it belongs. Data ownership, route data and release configuration are checked the same way.

A clean handover. OES set up the end-to-end test infrastructure and a guide the client’s external test team could work from. The handover itself was an export, not a copy: the client got the application they bought, with a record of where it came from.

The outcome

The platform was running in the client’s Azure network about six weeks after the first commit. A client team joined from late June and built on a structure that already said no to the wrong things.

After handover, the team raised the platform’s underwriting capacity by more than 130% in a week. The change landed in the rules, database and domain packages, and the web app only had to display it. Nothing was rebuilt, and OES wasn’t needed. The team has extended the architecture checks rather than disabling them, they still gate every production deploy, and a second product has since adopted them.

What this means for you

A prototype shows what a product should do. The decisions that decide whether it survives contact with real data, a growing team and the first big commercial change are the ones it doesn’t show: where the business rules live, who owns the data, and what enforces the structure once the original engineer has gone.