Scaling Retool apps when single-page architecture hits its limit
Single-page Retool apps work great until program count grows and each accumulates hundreds of fields. Page weight compounds. Query execution slows. Switching between contexts feels heavy.
I work at Stackdrop, a Retool-certified partner in EMEA, and we ran into this with an insurance underwriting workbench. The original build loaded every component and query regardless of which program an underwriter was using. At five programs, it felt fine, but at fifteen, it became unusable.
The fix was not query optimization or caching. Those help at the margins. The structural problem was the architectural scope.
We moved to a multi-page architecture split into two stages: submission writeup and pricing coverage. Each stage only loads the components and queries it actually needs. The writeup stage surfaces conditional fields based on business line selection. Cyber submissions pull Bitsight scores and cloud provider data. D&O submissions pull equity history and asset records. Irrelevant fields stay hidden, which trims payload size and matches how underwriters actually move through a submission.
The pricing stage uses a four-variable filter to isolate one of fifteen programs. Program-specific schemas trigger through numbered buttons instead of conditional hide-show logic inside one heavy page. Global inputs establish baseline pricing that underwriters can adjust before committing. A JavaScript query handles modifier re-rating by updating the state of each coverage option and recalculating prices in real time.
The migration happened program by program. Each program became a self-contained module, tested independently, and released sequentially. The legacy interface stayed live as the source of truth until each new module passed validation. Underwriters kept working throughout. No cutover moment. No downtime.
Two technical patterns that made this work:
- Query scoping at the page level instead of the component level reduced initial load time by limiting database calls to what the current stage actually requires
- State management for modifiers used a single source of truth that cascades changes across all dependent options without manual re-entry
Has anyone else migrated a live Retool app from single-page to modular architecture? What patterns worked for keeping the system stable during the transition? (Let me know if you want to know more about this use case, we wrote about it in detail)