Rebuilding an underwriting app that outgrew itself, one program at a time.

The underwriters wrote policies in the workbench every day, and it kept getting slower. Opening a program, entering a field, or switching between programs meant waiting. The app could not go offline, because live submissions ran through it.

The client is an insurance underwriting platform working across 15 programs and three carriers. Its Retool workbench served the operation well when it was built. Then the business added programs, carriers, and coverage complexity, and the app grew organically to match.

Before

The workbench was one page. Every query and every input field loaded at once, whichever program an underwriter had open. Each program carried hundreds of fields, so the page got heavier with every program added.

Queries that were fast at the original scale fell behind. The interface had grown without an organizing logic, and underwriters moved between programs inside one heavy screen. Rating had a gap as well. A global modifier did not flow into each coverage option, so displayed prices could go stale.

What we found one level down

The features worked. The structure was the problem: one page carrying work that belonged to different stages and different programs. Faster queries alone would not have changed that.

The constraint shaped the plan. Underwriters could not stop writing policies, so a single cutover was out. We rebuilt the workbench one program at a time. Each program was rebuilt, tested, and released before the next began, and the original app stayed live throughout. There was no day the system was unavailable.

What we built

Two stages, two pages. The flow split into submission write-up, and pricing and coverage. Each page loads only the components and queries its stage needs.

A write-up that follows the business line. Underwriters see submissions joined to company data: App ID, submission date, legal name, business line, layer, and broker. The detail form has 18 fields, and only those relevant to the selected business line appear. A Cyber submission surfaces Bitsight score, cloud provider, backup frequency, and records counts. A D&O submission surfaces equity fundraising history and total assets. Validation follows the same rules.

Pricing built per program. A four-variable filter narrows to one of 15 programs across three carriers: nine with the first, five with the second, and one with the third. Each program has its own schema. Global inputs set baseline pricing that underwriters can override and save. An options builder configures coverage for custom policies, and a dedicated dialog handles manuscript endorsements. A finished write-up moves to quote generation in one bulk database commit.

Re-rating that cascades. A JavaScript query now applies a modifier to every option, re-renders, and re-rates the whole write-up. Prices update across all options without manual re-entry.

Rating math the client owns. A technical lead on the client side built the rating logic for all 15 programs. In the rebuilt workbench, that person reviews and adjusts the rating math directly, without waiting on a developer.

The client already ran on Retool, and Retool's team made the introduction. The whole rebuild stayed inside Retool's components and workflows, with no custom code. Underwriters never had to change tools while their old one was being replaced.

What changed

The waiting stopped. The interface now follows how an underwriter moves through a submission: write it up, then price it.

The split was not what underwriters expected. They were used to having everything in one place, as in a spreadsheet. Separating write-up from pricing did not look like an improvement at first. Once they used it, they preferred it. The team agreed to carry the same structure across every remaining program, and gave our developer room to keep improving the interface.

Routine rating changes no longer wait on a developer. That keeps the workbench current as programs and coverage structures change. The patterns behind the rebuild are in a one-line change should not take three weeks and keeping internal tools fast as they grow.