Decompose the part that blocks the deploy, not the ugliest part

Legacy systems invite taste-driven rewrites: the module everyone hates, the naming that offends, the framework that feels old. Those projects stall because they do not unlock a shippable path.

Start with whatever currently gates the release. Decompose that seam first and the rest of the system becomes optional work instead of a hostage situation.

Gate the release, not the aesthetic

If deploys wait on a brittle shared library, that library is the first cut. If onboarding waits on a monolithic admin screen, that screen is the first cut. Ugliness without a gate can wait.

1. 01
   Name the release blockerOne sentence: what prevents a safe weekly deploy today? That answer picks the module.
2. 02
   Carve a seam you can ship behindFeature flags, adapters, or a strangler path so the new piece can go live without a big bang.
3. 03
   Leave the rest ugly on purposeDocument the debt. Do not let it jump the queue until the gate is gone.

How we choose the first cut

Legacy rewrites stall when they start with taste. Start with whatever gates the release instead.

Ugly code that ships weekly is healthier than elegant code that ships never.

What the first slice looks like

A thin adapter, a tested path through the blocker, and a rollback. Celebrate when deploys resume — not when the architecture diagram looks clean.

A short test

Ask: if we rewrote this module and nothing else, would deploys get safer next month? If the answer is no, you picked taste over the gate.