the question that matters
most businesses frame the rebuild-vs-patch question as a cost question. it is not. it is a capability question. the right starting point is: what does this business need to do in the next twelve months that the current site cannot do?
if the answer is 'nothing different — just fewer bugs and a faster homepage', the answer is almost always patch. if the answer involves a new product line, a booking system, a subscription flow, or a payment layer the current codebase was never designed to hold, rebuild becomes the cheaper option over time.
three signals that say patch
specific pages are slow, not the whole site. a performance audit that surfaces three pages with unoptimised images and two redirect chains is a patch job — targeted, measurable, reversible. the architecture is not the problem.
the design feels dated but the structure works. a visual refresh — new fonts, tighter spacing, updated colour application — leaves the underlying code untouched. this is a redesign, not a rebuild.
one or two features are broken. a contact form that stopped sending emails, a gallery that does not render on mobile, a map embed that lost its api key. these are patches. the site works except where it does not.
three signals that say rebuild
adding a new product category requires touching more than five files. this is the clearest signal. when a content change requires developer involvement because the structure was never designed to extend, the maintenance cost grows every quarter.
mobile performance is under 30 on google pagespeed. a score that low is usually a structural problem — a framework that ships too much javascript, a template that was never optimised for the network its customers use. performance at this level is rarely patchable without reworking the render path.
the developer who built it is unreachable and no one else understands the code. a codebase without documentation and without a maintainer is a liability. the rebuild question is not if — it is when.
how we approach it
when a business comes to us with a 'the site needs work' brief, the first thing we do is read the code. not skim it — read it. we look for the seams: where is the data model, how does the content get in, what does adding a new page actually require. the recommendation comes from the code, not from a preference for new builds.
the patch recommendation is more common than businesses expect. a codebase that is structurally sound and cleanly maintained is worth extending. we write the diagnosis in the scoping note, with both options side by side, so the business can make the call with the numbers in front of it.