Rebuilding versus refreshing: the questions we get asked most

Teams tend to reach for this after something has already gone wrong. The questions about rebuilding versus refreshing that come up most often on our calls.

Strategy work is mostly deciding what not to do, and writing it down so it stays decided. It is the sort of thing that looks like polish right up until it costs you an enquiry.

Do we need to care about this?

A rebuild is not always the answer. None of that requires a large budget, only a decision and someone to own it. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.

Can it wait until after launch?

Occasionally. More often the post-launch version costs several times the pre-launch one. It is worth being explicit about, because assumptions differ quietly.

How do we know it is working?

Rebuild when the platform blocks what you need to do. The reasoning matters more than the rule, because the rule has exceptions. The failure mode is not doing it wrong, it is doing it once and assuming it stays done.

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
• If the structure is sound, styling and content may be enough — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Most of the value here comes from doing the first two things, not all of them.