An old-looking website does not automatically need a complete rebuild. A website that still looks attractive may have more consequential problems: contact forms fail, the team cannot update information, or adding one service requires changes in several places.
Start with what the website currently prevents the business from doing. Then determine whether the problem is local to a few pages or rooted in a structure the team can no longer maintain. Evidence makes proposals comparable beyond their homepage mockups.
Turn “the website is bad” into a testable task
Collect actual incidents: customers cannot find a service's scope, people call for information that should be online, or routine content changes take too long. Identify the page, the user and the outcome they were trying to achieve.
Traffic data can indicate where to investigate, but a departure from a page does not explain the reason by itself. Someone may have found an answer or encountered a problem. Combine analytics with customer questions, observed tasks and contact-form outcomes.
The GOV.UK guidance on learning user needs recommends existing evidence together with interviews and observation, treating unsupported opinions as assumptions. This principle helps prevent a rebuild from beginning only with internal preferences.
Give likely customers an important task, such as finding the relevant service, understanding what to prepare and contacting the team. Observe where they stop without first telling them which button to use.
A content problem may allow a content-first improvement
Unclear service explanations, navigation labels customers do not understand, or an elusive contact route may be improved within the current system. Start with a page that matters to an important journey and test whether the task becomes easier.
Oversized images and unnecessary page elements can also be local problems. Identify the actual cause before declaring the entire platform slow. Moving the same assets and loading behaviour to another platform may simply move the problem.
Small edits are not always economical, however. If every page contains separately maintained copies of shared content and layouts, common structure may need attention even when the intended visual change is modest.
Prove the scope of a platform constraint
Identify the specific limitation: perhaps the team cannot assign appropriate editing rights, a new content type requires manual changes on every page, or there is no maintainable update path with an accountable owner.
Separate inconvenience that can be addressed through configuration or training from a constraint that requires structural change. Ask for examples and an explanation rather than accepting the age or novelty of a technology as sufficient evidence.
If access to code, hosting or important data is missing, investigate ownership and handover first. The next step may be recovering authorised access and collecting existing materials, rather than immediately replacing the website.
Compare both approaches against the same scope
Ask the improvement and rebuild proposals to address the same requirements, including content, forms, both languages, old links and handover. A one-page update and a complete replacement cannot be compared meaningfully on price alone.
Include the transition work. Who keeps the existing website current while the replacement is built? How do those content changes reach the new version? Where will the links customers previously saved lead after the switch?
Identify information that must remain available, such as article histories, images, downloads and outstanding enquiries. Check that the new system preserves its meaning, not merely that it can import a file.
Account for ongoing ownership as well. A lower initial effort can still leave a recurring maintenance burden, while a more extensive replacement can introduce responsibilities the team has not prepared to handle.
Use a small trial to resolve a large uncertainty
If the choice remains unclear, prototype a representative page or process. For example, test a service page with two language editions and a working contact flow in a test environment. Examine both the customer's experience and the editor's tasks.
Define criteria before the trial: people can locate the necessary information, the form reaches its responsible recipient, the team can change images and text without damaging shared structure, and responsiveness suits the devices customers use. Visual appeal should not be the only condition.
Once the approach is chosen, organise work around the required outcomes and retain what already works. Recheck the same tasks and measures after the change, with a recovery path if an important function is incomplete.
Use the business-enquiry website checklist to identify which journey deserves attention first. The website brief and acceptance guide can then turn the decision into a scope that both the business and delivery team understand.
Your current website has problems, but a full rebuild still feels hard to justify?
Talvyn Labs can examine failed customer and team tasks, identify focused improvements and plan a replacement where the existing constraints justify it.
Assess your website's next step