A client asking for a rewrite is often telling you where the pain shows up, not what caused it.
That distinction matters because technology teams are trained to respond to requests. A stakeholder says the system is broken, the backlog fills with replacement work, and everyone starts debating architecture before anyone has watched the work happen. The project feels productive because motion is visible.
Motion is cheap. Understanding is where the money is.
In one case, a team was ready for a full application rewrite. The real problem was closer to 15 or 20 hours of targeted fixes. A person was losing 14 hours a week to data entry because the process had quietly grown around defects everyone had learned to tolerate. The software looked like the issue because the workflow had been compensating for it for too long.
Discovery is not a phase to get through. It is where the economics of the work are decided. Shadow the user. Ask why until the first answer stops sounding complete. Define success before the first sprint, because a solution without a scoreboard can only be judged by whether it exists.
The cheapest project is not the one with the smallest estimate. It is the one that solves the right problem before the wrong one becomes a program.
Related episode: 'The Solution-First' Trap: Why Projects Fail Before They Start.
