Does Your Website Actually Need a Rebuild?
Contact a new agency about a problem with your website, and the conversation can quickly turn into a proposal for a completely new one. You wanted a broken form fixed or a layout sorted out. Now you are discussing a redesign, a platform migration and moving all your content.
For most ordinary website problems, that is an unnecessarily expensive answer. My starting point is to repair what is there. A few broken parts rarely justify replacing everything around them.
Why the quote jumps to a rebuild
A new build lets an agency work with its preferred platform, templates and development process. Repairing an existing site means understanding somebody else's decisions, including the awkward ones.
It is understandable that a supplier might prefer a fresh start. But its preferred way of working is not, by itself, a reason for you to buy a new website.
The useful question is whether the existing system can do what you need after a sensible repair. That requires someone to inspect it. A rebuild recommendation made before that investigation deserves some scepticism.
Messy code is not a write-off
A website can have inconsistent code, an untidy theme or a collection of old customisations and still be perfectly repairable. You do not need to make the entire codebase elegant before you can make a form work properly.
Often, the right job is quite local: correct the mobile menu, replace a troublesome component, simplify a page template or repair a connection to another service. Some surrounding code may need cleaning up so the change is safe. That still does not mean starting again.
Suppose staff find it difficult to edit a group of pages. A developer might be able to build a reusable template within the existing CMS. The business gets a better editing experience without moving its content, retraining everyone on a different platform or rebuilding unrelated features.
There is a difference between code that is unpleasant to work on and code that cannot reasonably be improved. A proposal should explain which problem you have, rather than using "messy" as a verdict.
Keep the parts that already work
The cost of a rebuild includes recreating things you already paid for and know how to use.
A working catalogue, a familiar publishing process, useful search pages and existing integrations all become things to migrate, recreate or retest. Even if the replacement looks better, that work still has to be done. Where URLs change, their old destinations need to be accounted for too; Google's site-move guidance describes the mapping and redirect work involved.
A focused repair leaves much more of that alone. It can be tested against a specific problem and released without waiting for an entire replacement site to be ready.
That is why improving the current site is usually the more efficient starting point. You spend the effort on what is failing instead of putting the working parts back into development.
Ask for a repair plan first
Tell the developer what is going wrong and ask them to investigate that, rather than asking what they would build from scratch.
A useful repair proposal should identify the fault, explain what needs to change and describe how the result will be tested. If one section is badly built, ask whether that section can be replaced while the rest stays in place. You can improve a website substantially without replacing its platform.
Repairs should still be proper development work: use a backup or test environment, understand the dependencies and check the behaviour the business relies on. "Keep the site" does not mean "make another hurried patch".
There are exceptions. A replacement can be justified when there is no practical way to keep essential software supported and secure, or when the platform genuinely cannot accommodate what the business now needs. But a new agency's preference, an old design or untidy code is not enough to establish that.
If you asked for a repair and received a rebuild quote, ask what prevents the repair. The answer should be about your website, not the supplier's preferred platform.