<aside> 🏗️ Discipline: Prove you understand the system before you replace it. Default: Iterate.

</aside>

Why Iteration Beats Rebuild

Existing systems contain embedded knowledge that nobody documented. Edge cases handled. Integrations tested. Failure modes discovered and patched. A rebuild throws away all of that learning and starts the discovery process over.

The new system will not have the same problems as the old system. It will have different problems, plus new versions of problems the old system already solved.

Five Checkpoints (All Must Pass)

• [ ] Can you replicate the current process manually? If not, the system contains logic you do not understand.
• [ ] Have you documented every edge case the current system handles?
• [ ] Is the technology genuinely incapable of iteration (not just difficult)?
• [ ] Does the Sponsor accept that rebuild introduces new, unknown risks?
• [ ] Does the team have capacity to support the old system while building the new one?

<aside> ⚠️ If any checkpoint fails, iterate instead. A rebuild proposal requires explicit answers to all five.

</aside>

The Manual Replication Test

Before rebuilding, try running the process manually. If you can replicate it, you understand it well enough to potentially rebuild. If you cannot, the existing system contains logic you do not understand, and a rebuild will rediscover that logic the hard way.