Start with an Audit: Turning Friction into a Business Case

Every platform carries decisions that made sense when they were made and friction that builds up quietly: a build that’s slower than it needs to be, a tool that’s no longer maintained, a step everyone does by hand. Someone new sees all of it with fresh eyes, which is a short-lived advantage worth using well.

Two tempting mistakes

• Living with it. After a few weeks the friction feels normal, and then it’s permanent.
• Fixing it piecemeal. Changing things one by one, without context, breaks what people relied on and spends trust you haven’t earned yet.

The audit, step by step

1. Walk the whole thing end to end. Build it, run it, deploy it, and list every improvement area as you go, the same way I’d read any new codebase (First Week in a New Codebase).
2. Ask why before changing anything. Many “odd” decisions have reasons that aren’t in the code: a deadline, a constraint that has since gone, a trade-off someone made knowingly. The reason tells you whether a change is safe.
3. Price each friction in business terms. Not “the build is slow” but engineer time per week, delivery speed and risk. Framed that way, improvements stop being a developer’s wish list and become a business case (Platform Adoption - Business Case and Rollout Rhythms).
4. Order the work by risk and payoff. Do first whatever unblocks the most, such as replacing an unmaintained build tool (Migrating from CRA to Vite), then the feedback loop (Cutting CI Feedback Time with Checkpoint Restarts).

Changing foundations safely

Swapping a build tool or framework is safest when the failures are loud: a page that won’t render is easy to spot, and good Observability makes it easier still. Walk every user journey on the new stack with the people who know them best, brief the team on what changed, and turn the journeys you mapped into automated smoke tests so the safety net outlives the migration.

Let a proposal change your mind

Earlier in my career I pushed to rewrite an internal site and was asked to bring a proposal and roadmap first. Writing it showed the job was far bigger than it felt and that other work mattered more, so we didn’t do it. The proposal still paid off: it earned trust, and bigger work followed. Make the case with evidence rather than enthusiasm, and be ready to lose the argument you started.

Related notes

Golden Paths · Strangler Fig Migration · CVE and CVSS for Dependency Risk