I recently found myself in a discussion with one of our frontend developers. We were pondering why companies often choose to replace entire frontend codebases rather than improve what they have. Despite the undeniable impact of frontend on user experience, there’s a strong tendency to start from scratch rather than improve what’s already there.

One reason is a common bias in leadership. Many CTOs and engineering leaders come from a backend background. Their instincts are shaped by backend principles—where stability and scalability often take center stage. As a result, they’re more comfortable assessing and improving backend systems. Frontend, in contrast, feels more volatile, leading to a preference for complete rewrites when things get messy.

Then there’s the ever-changing landscape of frontend technology. A new framework every other month, shifting best practices, browser quirks, and growing complexity in build tools. It’s no surprise teams often feel like they’re constantly behind. The temptation to jump on the next “shiny thing” as a reset button is strong.

Finally, there’s a tendency to underestimate the complexity of frontend work. Many still see it as “just the interface,” something that doesn’t require the same rigour as backend systems. This underestimation often results in underinvestment, leading to a mountain of technical debt that feels insurmountable.

Rather than defaulting to a rewrite, we should invest in understanding the true cost of both options. Refactoring may be slower and messier in the short term, but it’s often more sustainable, less disruptive, and kinder to your team—and your users—in the long run. It requires strong technical leadership on the frontend, the same way we expect it on the backend. It calls for respecting the craft and complexity of frontend engineering and giving it the same seat at the table.

Because while shiny new codebases are exciting, long-term value often lies in evolution—not revolution.