The real cost of ignoring rebuilding versus refreshing
We end up explaining this on discovery calls often enough that it deserved writing down. Nobody bills you for neglecting rebuilding versus refreshing. The cost shows up somewhere else.
Strategy work is mostly deciding what not to do, and writing it down so it stays decided. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.
Where the cost lands
- Time spent on work that should not have been necessary
- Enquiries that quietly never arrive
- A rebuild is not always the answer
- Rework, once the problem is finally visible
If the structure is sound, styling and content may be enough. Getting it slightly wrong is survivable. Ignoring it entirely is not. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.
Turning this into a decision
Rebuild when the platform blocks what you need to do. Where this goes wrong is almost never a lack of knowledge. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.
In practice
The projects that go badly are rarely the ones with the hardest technical problems. Three things worth confirming about rebuilding versus refreshing before you move on:
- Someone can say what the current setup is without going to look
- A rebuild is not always the answer — and you know whether that is true here
- There is a way to tell whether the last change to this helped
If you want a second opinion on how yours is set up, ask.