Fix a website feature when its purpose is still right and you can isolate the defect. Rebuild it when the feature’s job, data model, dependencies, or failure pattern has changed enough that patches no longer produce a predictable result.
The decision isn’t “old code versus new code.” Old code can be stable, and a new build can reproduce the same confusion. Start with the job the feature must complete.
Write down what the feature must do
Name the user, trigger, expected result, stored data, outside systems, failure response, and person who owns the outcome. A contact form, for example, is not just fields and a submit button. That work may include validation, consent, spam handling, delivery, storage, routing, confirmation, and a staff response.
Test those steps before reading a pile of old tickets. If one step fails under a specific condition while the rest remains sound, a focused repair may be enough. If nobody can agree on the expected result, code changes are premature.
Find the fault you can repair
A repair is easier to justify when you can reproduce the problem, identify the responsible layer, change it without replacing unrelated behavior, and verify the result with a clear acceptance test. Record the failing input, actual result, expected result, environment, and recent change history.
Do not confuse a visible symptom with the responsible layer. A button that appears broken may be blocked by validation, a network request, a permission check, or an unavailable outside service. Replacing the button won’t fix those causes.
Recognize rebuild signals
Consider a rebuild when the feature solves the wrong job, depends on unsupported components, stores data in a shape that cannot support the required behavior, has several interacting defects with no reliable tests, or requires repeated patches that each break another path.
A rebuild also needs boundaries. Decide which behavior, content, data, URLs, accessibility qualities, and integrations must survive. Inventory the migration and rollback work. “Start fresh” isn’t a plan when the old feature contains customer records or business rules.
Compare the smallest credible options
Write two short scopes: the smallest safe repair and the smallest useful rebuild. For each, list the assumptions, data changes, downtime, tests, rollback, ongoing ownership, and what remains unresolved. The cheapest first step may be a diagnostic that makes both estimates more honest.
This is the same discipline behind deciding whether a site needs a redesign or better content decisions: choose the layer that owns the problem. Put the chosen scope and completion evidence into a website project brief.
If a repair can get the feature doing its job again, with someone responsible for maintaining it, fix it. If the job has changed beyond what the existing feature can support, plan a rebuild. Either way, judge the work by the user’s completed job, not by the amount of code replaced.
TechDex Presents…
Flashback to the ’90s
Get 2026 services at 1990s prices.
For a limited time, I’m rolling prices back on six focused small-business services. Choose one service for $800, or choose two for $1,200. Nothing is purchased here—I’ll review your request and confirm the scope with you first.
For related website work, explore this Rewind service:
The campaign form lets you choose one or two services and request a follow-up. It isn’t a checkout, and you won’t be billed when you submit it.