Every broken product eventually surfaces the same conversation. Someone — usually an engineer, sometimes a frustrated product leader — makes the case for a clean slate. New platform. New stack. Start over and do it right this time. The argument is always emotionally compelling and almost always strategically wrong.

I've been in that conversation more than once. And I've learned that the teams who default to rebuild are usually solving for their own frustration rather than the problem. A messy codebase, a legacy architecture, years of accumulated technical debt — these are genuinely painful. But guest-facing product problems are almost never solved by fixing the plumbing. They're solved by fixing what the guest touches.

The question is never "is it broken?" Everything breaks. The question is what exactly is broken, whether a fix is faster than a rebuild, and what the real cost of getting it wrong is.

Why rebuild feels right — and usually isn't

The rebuild argument has a seductive logic. If the foundation is bad, anything you build on top of it is compromised. Better to tear it down now than to accumulate more debt on top of a broken base. This is true in theory and almost irrelevant in practice.

In practice, rebuilds take longer than estimated, cost more than planned, and frequently reproduce the original problems in a new environment because the team didn't understand what was actually causing them. The new platform inherits the old assumptions. The same decisions get made under pressure. And the guests who were suffering through the broken experience have now been suffering through it for eighteen months while you rebuilt.

The fix argument requires more intellectual rigor — which is why teams avoid it. You have to understand the problem precisely. You have to know which parts of the system are actually broken and which are just ugly. You have to be honest about whether a targeted fix will hold or whether it's a band-aid on a structural fracture. That work is harder than starting over, and it requires you to sit with a broken thing long enough to understand it.

The four questions I ask before making the call

Question 01
What is the guest actually experiencing?
Not what the system is doing wrong architecturally. What is the guest experiencing? Is it one broken flow, or is the entire journey compromised? The answer to this determines the scope of the fix — and often makes rebuild look unnecessary.
Question 02
Is the failure in the frontend or the foundation?
Guests experience the frontend. If the frontend is broken and the backend is stable, you can fix what guests see without touching the plumbing. Most product failures live in the frontend. Most rebuild arguments live in engineering.
Question 03
What is the actual cost of each path?
Not the estimated cost — the honest cost, including timeline risk, team disruption, and the cost of keeping guests on a broken experience while you rebuild. Rebuild estimates are almost always optimistic. Fix estimates are usually accurate.
Question 04
What breaks if you fix it incrementally?
Sometimes the architecture won't allow targeted fixes without cascading failures. If that's true, you need to know it before committing to a fix path. But you need to verify it, not assume it — engineers who want to rebuild will say this is true more often than it is.

How we applied this to the Jack in the Box app

When I took over the app, the rebuild conversation was already happening. The rating was 2.6. Guests were churning. Engineering had a proposal for a new platform. The case looked strong on the surface.

We didn't rebuild. We decoupled the frontend from the backend and rebuilt only the frontend — the part guests actually touch. The backend stayed intact. That single decision cut the timeline from what would have been a multi-year platform migration to an eight-month product rebuild. We shipped a 4.8-star app in eight months because we correctly diagnosed where the problem actually lived.

The backend was ugly. It still had issues. But the guests weren't experiencing the backend — they were experiencing the authentication flow, the offer redemption UI, the checkout sequence. We fixed those things. Specifically. The rating moved because the experience moved, not because the architecture was clean.

We rebuilt what was broken. Everything else stayed. That discipline — knowing what not to touch — is harder than it sounds and worth more than any clean-slate rewrite.

When rebuild is actually the right call

There are situations where rebuild is correct. When the frontend and backend are so tightly coupled that you cannot change one without breaking the other. When the technology is genuinely end-of-life and security risks are compounding. When the team maintaining the system has turned over completely and institutional knowledge of the original design is gone. When the business model has changed so fundamentally that the existing architecture cannot support the new direction.

These situations exist. They're real. And they're rarer than the rebuild arguments that get made in product planning sessions.

The test I apply is simple: can I fix what the guest is experiencing without touching the foundation? If the honest answer is yes, the rebuild argument is premature. Fix the experience. Schedule the architecture work separately, on its own timeline, with its own business case. Don't hold the guest experience hostage to an infrastructure decision that can be decoupled from it.

The goal is never a clean system. The goal is a working product. Sometimes those are the same thing. More often than engineers would like to admit, they're not.