Laravel

Most Laravel work I get called into is on a codebase someone else built. Either the original developer has moved on, the agency relationship has ended or the team has grown past the point where one person knows the whole app. The first question is almost always the same: refactor or rebuild?

These posts answer that question in the slow, boring way it deserves. Rebuilding feels decisive but usually buys you a fresh codebase with the same business assumptions baked in. Refactoring feels slow but tends to leave you with a working app, paying customers and a team that still trusts the system. The right call depends on how much of the existing code is still earning its keep.

Posts here cover the diagnostics: how to read an inherited Laravel app quickly, where to look for the parts that will break first, how to budget for a refactor in stages and what a sensible maintenance retainer should include. They also cover the technical detail: long-running queue jobs, package version drift, test coverage in legacy code and the cost of staying on an unsupported Laravel version.

If you have inherited a Laravel app and you are not sure where you stand, when to rebuild vs refactor is the right starting point. For ongoing help, I take on Laravel support work as part of the support and maintenance service.