Redesign or rebuild

The decision usually presents itself as a budget question — redesign is the cheap option, rebuild is the expensive one — and gets settled by whichever number the team can defend. That framing reliably produces the wrong answer, because the two are not different sizes of the same job.

A redesign changes what the product looks like and how it is organised. A rebuild changes what it is made of. They fix different faults, and either one applied to the other's problem produces an expensive version of what you already had.

The question that separates them

Ask where the problem actually lives: in the decisions, or in the material?

If people cannot find things, if the structure does not match how anyone thinks about the work, if the product looks like it was assembled rather than designed — those are decisions. New code will reproduce them faithfully.

If every change takes a week, if nobody can say what will break, if there are states the team cannot reach to test — those are material. A new coat of design sits on top of them and changes nothing about why shipping is slow.

Rebuilding to fix a design problem gets you the same product in newer code. Redesigning to fix an engineering problem gets you a better-looking product that is still frightening to change.

Signals it is a redesign

• Support answers the same "where is…" question repeatedly. That is a structure problem, and structure is a design decision.
• The navigation has grown a "More". Almost always the point where a model stopped fitting and nobody revisited it.
• The product has outgrown its own vocabulary. It was built for one thing and now does three, with the original words still on the buttons.
• The team describes the product differently from the interface. When the pitch and the screens disagree, the screens are out of date.
• It works, but nobody is proud of it. A real signal, and not a vain one: in a competitive market, looking unmaintained is read as being unmaintained.

Signals it is a rebuild

• Estimates have stopped being meaningful. Small visible changes cost what large ones should, and nobody can explain the difference in advance.
• There is code nobody will touch. Not because it is complex — because the consequences of touching it are unknown.
• The same bug keeps returning somewhere new. A sign the fix is being applied to symptoms because the cause is unreachable.
• You cannot run it realistically. No way to see the states that matter without production data, which means they are never properly tested.
• The platform underneath is ending. A dependency with no upgrade path is a deadline whether or not anyone has written it down.

Notice that none of these are about appearance, and none of the previous list are about speed. When a product shows signals from both lists, it has two problems, and the useful next step is to say so out loud rather than pick one word for the project.

The option nobody puts on the slide

Both words describe replacing everything. Most products do not need that, and the all-at-once version is where rewrites go to die: a long period with two products, one earning money and one absorbing attention, and a launch date that moves because it has to be complete before it is useful.

The incremental version replaces one surface at a time, behind the existing product, so each piece ships and earns on its own. It is less satisfying to plan and much harder to abandon halfway, which is its main advantage: a stalled incremental migration leaves a working product, and a stalled rewrite leaves two broken ones.

It also lets the two problems be separated in time. Fix the material under the worst surface first, then redesign it; or redesign the structure on the existing material and rebuild underneath later, once the shape has stopped moving.

When it is a marketing site, not a product

For a site rather than an application the calculation is different, because the material is cheap and the decisions are almost everything. A marketing site is a fixed set of pages whose job is to be understood and to be found.

There the rebuild question is usually narrower than it looks — not "what framework" but "what does this page contain before any JavaScript runs", which is a build-step question more often than an architecture one. That is set out in React or Next.js for a marketing site.

HYS Games is a case in point of the shape: a game studio website designed and built end to end, where the structure and the material were decided together rather than one inherited from the other.

How to actually decide

1. 01Write down the five complaints you hear most, in the words people use.
2. 02Sort each into decisions or material. Anything you cannot sort is probably a symptom — follow it until it lands on one side.
3. 03If they are nearly all decisions, you have a redesign, and rebuilding first would mean doing the design work twice.
4. 04If they are nearly all material, redesigning first puts new paint on the thing that is actually slowing you down.
5. 05If they are split, name both, pick the one blocking the other, and do that first — incrementally, so the other can start before it finishes.

If you are weighing this up and the list comes out split, tell us what you are building.