Reinsurance underwriting platform: prototype to production in six weeks
A clickable prototype with no backend became an underwriting platform running in the client’s private Azure network about six weeks after the first commit.
- Sector
- Reinsurance
- Role
- Architect and lead engineer. Solo for the first two months, then top contributor on a five-person team.
- Timeline
- Spring and summer 2026, handed over in September
- Stack
- SvelteKit, TypeScript, Postgres, Azure, Terraform
Outcomes
- 6 weeks From the first commit to running in the client’s private Azure network.
- 520 of 523 First commits written by me, working alone for the first two months.
- 50MB to 38KB Heaviest page response, for a real submission with nearly 14,000 locations.
- 55% Of all commits once the team of five was in place, and 23 of 25 merges to main.
- 8 Deploys blocked by the architecture checks since the team joined. Each one was fixed in the code, not by switching a check off.
- 1 week For the team to change the platform’s underwriting limits after handover. It was a rules and database change, not a rebuild.
The starting point
The brief was a clickable prototype. It showed 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 the 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.
Decisions made early, alone
For the first two months it was just me, so I made the calls a team would normally argue about. I set up the monorepo and wrote the core packages: the web app, a background worker, the rules, the database and the domain types. I decided where the business rules live, which package owns which data, and what a coding agent is and isn’t allowed to touch.
I used coding agents for a lot of the build. The speed came from deciding those things early, and then 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.
At the time that looked like extra structure for a product with one client and a short deadline. After handover, the team changed the platform’s underwriting limits 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.
Real data bites
Real submissions don’t look like demo data. The median submission had 26 locations. The largest had nearly 14,000, and the page for it was sending two duplicate responses totalling about 50MB and timing out. I cut that to 38KB.
Production found other edges too: a background worker running out of memory on an 889MB spreadsheet, an integer overflow on a large location value, and database deadlocks returning errors. Each one got fixed at the cause. I also extended the generated quote from 5 pages to 14 so it matched the client’s own package.
Checks that outlasted me
An architecture document gets read once. I turned the boundaries into a checker that parses the TypeScript and Svelte source, fails when code lands in the wrong place, and says where it belongs. It has 36 blocking rules, alongside checks on data ownership, route data and release configuration.
When the team joined they were building on a structure that already said no to the wrong things. Those checks blocked 8 deploys, some of them my own agent’s code. The team extended the rules rather than disabling them, and the checks went to the client with the handover. They still gate every production deploy.
Handover
For the client’s external test team I set up the end-to-end test infrastructure, with 281 test IDs in five tranches and a guide to running them. 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 platform is live, and the team is still shipping on it.
Have a prototype that needs to become a product?
Tell me what it is and when it needs to ship. Email is the quickest way to reach me.