While working on a new ticket, I noticed five claim modals were using a raw Dialog component with inconsistent styling across each one. A sixth modal, elsewhere in the codebase, already used the shared Modal component from our internal design system.

The instinct in the moment is to just fix it, you're already in the file, you can see the problem, why not clean it up right now? But folding an unrelated fix into your current PR is exactly how a tightly scoped change turns into a thirty-file diff that nobody can review properly.

Instead of fixing it inline, I created a separate ticket for the modal migration and kept the original PR scoped to what it was actually meant to do.

This matters for a reason that's easy to underestimate: a reviewer can reason confidently about a small, focused diff. The moment unrelated changes get mixed in, review quality drops, either the reviewer has to context-switch between two unrelated problems, or they rubber-stamp the unrelated part because it "looked fine while skimming." Neither outcome is good. Splitting the work protects the thing you actually shipped today, and gives the cleanup the dedicated attention it deserves later.

When I came back to do the modal migration, the fix was to move all five modals onto the Modal component that already existed and was already proven in production, not to design a new abstraction on top of Dialog.

This is the detail that separates good opportunistic refactoring from scope creep wearing a disguise. Introducing a new abstraction means new edge cases, new tests, and a new pattern for the team to learn. Migrating to something that already works elsewhere in the codebase is low-risk and immediately legible to anyone who's seen the Modal component before. "Improve while you're here" is only a good instinct when the improvement reduces inconsistency rather than adding a new one.

A data inconsistency surfaced that had a direct monetary impact. My first instinct, and the right one at this stage, was to investigate broadly, tracing every place the inconsistency could originate from, not just the symptom that got reported.

Understanding the full scope before deciding what to fix is not the same as committing to fix all of it at once. You need the broad picture to make a good decision about where to draw the line for the urgent fix. Skipping this step is how you end up with a fast patch that misses a second source of the same bug.

Once I understood the full extent of the problem, I deliberately narrowed scope to the smallest change that stopped the monetary impact, not the most complete fix, the safest fast one.

When money is actively being affected, the priority is stopping the bleeding, not elegance. A large, sweeping fix takes longer to write, longer to review, and carries more risk of an unrelated regression, exactly the wrong tradeoff when the cost of delay is measured in pounds per hour. The smallest safe fix that addresses the critical path buys you time to do the rest properly without pressure.

The wider mapping work, the more complete fix that would prevent the entire class of inconsistency, not just this instance, became its own ticket, to be picked up once the immediate risk was contained.

This is the same discipline as the modal migration, applied under pressure instead of opportunistically. The urgent fix ships fast because it's small. The broader fix gets done properly because it's no longer racing against an active incident. Trying to do both in one pass usually means doing both worse.