We Rebuilt the UI Instead of Refactoring It

We introduced a new entity to our data model and needed to update several pages. We could have threaded it through each old implementation. Instead, we rebuilt the affected UI components. That was faster and let us leave their Flow types and stale assumptions behind.

The Math Has Changed

Much of our codebase predates TypeScript. Some components still use Flow annotations. When facing large changes, scaffolding new components with current patterns beats incrementally modernizing legacy code.

That does not make rebuilding a general rule. It made sense here because the new entity crossed several UI components while the behavior and business logic remained easy to compare with the old pages.

What Made the Rebuild Cheaper

Cursor had replaced VS Code as my default editor. Its project context made scaffolding the replacement components cheaper, especially when the old and new implementations had to be compared side by side.

When to Rebuild

I would not apply this rule to critical systems or dense business logic, where the old behavior is often more valuable than the old structure. For feature-level UI, though, the threshold moved. In this case the replacement was the smaller change because it avoided carrying the old architecture into every page the new entity touched.