A website problem does not automatically require a new website. The useful question is smaller: what is stopping the right visitor from understanding, trusting or acting, and how much of the current site must change to remove that obstacle?
Repair when the intended journey is already sound
A repair is appropriate when the site still has the right pages and message, but a specific part has failed. Broken forms, display defects, failed integrations, update errors and obvious accessibility faults often belong here. The job should begin with reproduction and diagnosis, then make the smallest safe change and check nearby behaviour for regressions.
Improve when the foundation is useful but underperforming
Improvement makes sense when the website works but asks too much of visitors. The opening may be vague, the mobile layout awkward, important pages difficult to find or the enquiry route needlessly long. This work can involve clearer writing, a better page order, stronger calls to action, faster delivery and more consistent design without discarding everything that already has value.
Rebuild when changes keep exposing structural limits
A rebuild becomes sensible when the audience, offer or required capabilities have changed enough that the old structure is fighting every improvement. It may also be justified when the system can no longer be maintained safely, nobody can explain how it deploys or several temporary fixes have made ordinary editing risky. A rebuild should solve those constraints, not merely replace the colours.
Inspect before choosing a scope
Look at the live site on a phone and desktop, send a real test enquiry, review the pages people actually use and identify who owns the domain, hosting and accounts. Check whether useful content can be retained and whether current search visibility depends on established URLs. This short investigation is usually more reliable than choosing a package from a symptom alone.
Ask what the least disruptive successful result looks like
Write one sentence describing the improved situation. It might be that enquiries arrive reliably, visitors can understand the offer within a minute or staff can update important details without calling a developer. Compare repair, improvement and rebuild against that result, including disruption, ongoing care and what the business will own afterwards.
A useful first brief
Send the website address, what appears to be going wrong, who it affects and whether a real date matters. You do not need to diagnose the technology or name the service. A responsible first response should clarify the problem before recommending the largest version of the work.
