Beware of rebuild bankruptcy

Rebuilds have an expiry date. Every day a team isn’t shipping the new version, they move one step closer to declaring bankruptcy on the effort.

Teams sometimes need to rebuild a feature because too many shortcuts were taken, documentation is minimal, or key people have left. A rebuild can be the right call, but it always comes with risk. The team has to support the old version while creating the new one. Bugs still occur, and customers still rely on the existing system. If maintaining the old version requires too much attention, the rebuild is postponed. Every time the rebuild is postponed, the work feels more distant and gets harder to pick up again.

The goal of a rebuild is straightforward: to get the new version into customers' hands as quickly as possible. Every week it sits unfinished, it loses relevance. Requirements shift, and the context fades. The people who wrote the early parts of it move on to other priorities.

I’ve seen rebuilds stall for months. When the team eventually returns to them, progress is slow and frustrating. In the worst cases, we’ve thrown the work away entirely because there was no realistic path to finishing it or shipping it.

If you decide to rebuild, guard the momentum. Ship early, ship in slices, and avoid letting the work sit. Because once a rebuild goes stale, reviving it is often more costly than starting over from scratch.