Try explaining the business benefits of refactoring to a non-technical stakeholder and you'll encounter a blank stare. The immediate response is usually that there is no business case — it doesn't deliver features, it doesn't generate revenue, and it's difficult to measure.

But the business case is there. It just needs to be framed correctly.

The real cost of not refactoring

A common pattern: a project is delivered quickly under commercial pressure. Tests are deferred, standards aren't enforced, and shortcuts are taken to hit the deadline. The system works — for now.

When requirements change, as they always do, what should be a small change requires touching many interconnected parts. Each change introduces new risk. Each bug fix potentially creates two more.

Multiply this across hundreds of features built under the same pressure, and you have a system where:

  • Bugs that shouldn't exist require developers to fix them
  • Feature delivery slows as the codebase becomes harder to navigate
  • Developer morale degrades — engineers who care about quality don't want to work in systems like this
  • Onboarding new developers takes months rather than weeks

All of this costs money. More developers to maintain a fragile system, higher turnover, slower delivery.

Refactoring as cost reduction

The frame that resonates with business stakeholders is cost reduction, not technical hygiene.

Refactoring reduces the number of developers needed to maintain a system. A clean, well-structured codebase is cheaper to maintain, faster to change, and easier to reason about — meaning the same team can deliver more, or a smaller team can deliver the same amount.

Concretely:

  1. Fix existing issues and enforce quality conventions. Establish PHPStan, Rector, and Easy Coding Standard in your CI pipeline. Every PR must pass before merge.

  2. Simplify aggressively. Simplify configs, reduce dependencies, eliminate unused code. If a non-technical person can't get a rough sense of what's happening, it needs to be simplified further.

  3. If starting a new project, set up the quality infrastructure first. The cost of setting it up correctly at the start is a fraction of the cost of retrofitting it later.

Once these steps are done, development velocity increases — because there's less friction, less debugging time, and less time spent understanding what existing code does.

The investment pays back disproportionately

Time invested at strategic points in getting things done properly saves a disproportionate amount of time later. When you have to deliver on the promises you made to close a deal, you want a system that can absorb the work — not one that resists every change.

Refactoring isn't an indulgence. It's infrastructure. It's the difference between a delivery pipeline that works and one that constantly catches fire.

The tools to do this systematically — Rector for automated refactoring, Indoctrinate for database layer modernisation, PHPStan for type safety — make the process measurable and incremental. You don't need a multi-month big-bang refactor. You need a consistent process, applied to every change.