Use Case | How an insurance underwriting team upgraded a Retool app that had outgrown itself, one program at a time

When an insurance underwriting platform built its workbench in Retool, the app worked. Coverage was handled across multiple business lines, underwriters had what they needed, and the system served the operation it was built for. Then the business grew with more programs, more carriers, and more coverage complexity, and the app accumulated weight it was never designed to carry. Page loads became slow. Queries fell behind. Simple actions like entering data or switching between programs required waiting that underwriters shouldn't have to do. The system couldn't be taken offline; underwriters were using it daily across active submissions. Stackdrop rebuilt it program by program, restructuring the architecture while the team kept working.

Why did the original underwriting app slow down as programs scaled?

The original workbench operated as a single-page application that forced every query and input field to load regardless of which program an underwriter was using.

As the number of programs grew and each accumulated hundreds of fields, the page weight compounded. Queries that were fast at a smaller scale became slow as coverage complexity increased. The UI had accumulated without a clear organizational logic, underwriters moved between programs inside a single heavy interface, and the waiting time was real.

The platform was not broken at the feature level, but the architecture had exceeded the scale it was originally designed to support. A single-page application that worked at one scale became a liability at the scale the business had reached, and the pattern was only going to continue.

How was the workbench rebuilt without taking the system offline?

Keeping underwriters working was the constraint. The approach was to rebuild program by program, each program rebuilt as a self-contained unit, tested, and released before the next one started, so underwriters moved to the rebuilt version progressively rather than in a single cutover. The original app stayed live throughout.

The first structural decision was moving from a single-page application to a multi-page architecture. The underwriting flow was separated into two distinct stages: submission write-up and pricing and coverage. This reduced page weight, scoped queries to what each stage actually needed, and gave the interface a logic that the original app had lost.

The write-up stage handles the submission itself. Underwriters see a joint view of submissions and company data, such as App ID, submission date, legal name, business line, layer, and broker details, and open a detail form with 18 fields. The fields are conditional: 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. Fields that don't apply to the selected line don't appear, and validation rules follow the same logic.

The pricing and coverage stage handles program selection and policy construction. 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, triggered by numbered buttons. Global Inputs set baseline pricing fields that underwriters can override and save. The Options Builder adds, removes, and configures coverage options for bespoke policy construction. Manuscript Endorsements handles custom endorsements through a dedicated dialog. When a write-up is complete, an efficient bulk database commit moves the submission from underwriting into quote generation.

How did underwriters respond?

The stage split was not what underwriters expected. Their instinct was to keep everything in one place because they think in spreadsheets, and separating the write-up from the pricing stage did not immediately seem like an improvement. The rebuild went ahead, and once they used it, the response reversed.

Performance is resolved, and the interface has a logic that matches how underwriters move through a submission. The team has agreed to carry the same structural approach across all remaining programs, and has given the developer latitude to continue adding interface improvements, a signal that came directly from how the first programs landed.

What does the client control without developer involvement?

The rating logic across all 15 programs was originally built by a technical stakeholder on the client side who understands the rating calculations at the level of their construction. In the rebuilt workbench, that person can review and adjust the rating math directly, without a developer change for every modification.

This matters for the same reason the program-by-program approach matters. A system stays current only if the people who need to change it can change it. Removing the developer dependency from routine rating adjustments keeps the workbench maintainable as programs and coverage structures evolve without creating a bottleneck every time the business logic shifts.

If you are evaluating a rebuild of an existing Retool system or want to map a program-by-program migration path, get in touch with the Stackdrop team.

FAQ

How was the original app rebuilt without breaking it while underwriters were actively using it?

The rebuild was structured program by program. Each program was rebuilt, tested, and released before the next one started. The original app remained live throughout. Underwriters moved to the rebuilt version one program at a time, which meant the architectural risk was distributed across the rebuild cycle rather than concentrated at a single release. There was no cutover moment, and no day the system was unavailable.

What caused the original app to slow down as the program count grew?

The single-page architecture loaded all components and queries together regardless of which program or stage an underwriter was working in. As the number of programs grew and each accumulated hundreds of input fields, the page weight compounded. The multi-page approach resolved this by scoping each stage to the components and queries it actually requires, so the load reflects what the underwriter is doing rather than everything the app contains.

How does re-rating work when a modifier is applied across multiple coverage options?

In the original app, global modifiers did not cascade reactively into program options. When an underwriter applied a modifier, the displayed prices became stale — reflecting the old calculation rather than the updated one. In the rebuilt workbench, a JavaScript query handles this: when a modifier is applied, it modifies the state of each option, triggers a re-render, and re-rates every option in the writeup. Modifier changes are reflected immediately across all options without manual re-entry. This required changing the state management architecture from the original app, but it closes the gap the old version left open.

Why was the workbench rebuilt in Retool rather than as a custom application?

The client was already operating on Retool. The Retool team made the introduction during the initial discovery calls. No custom code was required for the rebuild; the complexity of the underwriting logic and the conditional form validation is handled within Retool's component and workflow structure. Staying in Retool also meant underwriters worked inside a familiar environment throughout the rebuild rather than being moved to a new tool while their old one was being replaced.