When to Fix vs Rebuild a Website

Fixing is the right default when the codebase is understandable, dependencies are supportable, and the product-market fit of the current UX is still strong. You want a path where each sprint reduces risk: security patches, performance wins, and measurable conversion improvements. If your team can describe the architecture in one page and tests or staging exist, lean toward fix-first with a clear technical debt budget.

Rebuild signals show up as repeated firefighting for the same class of failure, or an inability to ship small changes without regression anxiety. If every feature request becomes a "we might break checkout" discussion, the system is telling you the foundation is too brittle for the roadmap you are selling. Another strong signal is vendor lock-in on an unsupported stack, where security and hosting costs rise faster than product progress.

Cost is not only build hours. Count opportunity cost: slow releases, lost organic traffic from technical debt, support hours, and executive attention. A rebuild that takes longer upfront but unlocks 2x release velocity can beat two years of incremental patchwork, but only if scope is controlled and migration of URLs, data, and integrations is planned like a product launch, not a weekend job.

A hybrid path often wins: fix critical path and performance now, then rebuild in slices (templates, sections, or modules) behind feature flags. This is common on WordPress, Shopify, and headless stacks when you must keep revenue live while modernizing. The mistake is starting a full rewrite with no production stability baseline; you will migrate bugs into the new system.

If you are unsure, ask for a short decision audit: business goals, current failure modes, cost of delay, and realistic timeline for fix vs rebuild. The output should be a one-page recommendation with risk, not a 40-slide sales deck. The right answer is the one you can staff, measure, and sustain.