What we check in a 48-hour Laravel rescue audit
A Laravel project that has stalled rarely fails for one reason. Usually a developer left, deadlines slipped, a few fixes were rushed, and now nobody is confident touching the code. At that point many teams start talking about a rewrite.
A rewrite might be the right call. But it is an expensive decision to make without evidence. A short, structured audit gives you that evidence first.
When an audit makes more sense than a rewrite
An audit is a good fit when:
- The app works in production, at least partly, and people depend on it.
- Changes take far longer than they should, or keep breaking other things.
- You have lost the developer who knew the system, and documentation is thin.
- You are getting quotes for a rebuild and want an independent view before committing.
If the code still encodes real business rules, such as pricing, permissions or invoicing logic, throwing it away means rediscovering all of those rules. An audit tells you how much of the existing system is worth keeping.
What the audit covers
Our rescue audit costs $500 and is delivered within 48 hours of getting access. In that time we focus on the questions that decide what happens next.
Can it run?
We try to get the application running from the repository. We note the PHP and Laravel versions, missing environment variables, broken migrations and any setup steps that only lived in someone's head. If it cannot be run cleanly, that is the first finding.
Dependencies and versions
We check the Laravel version against supported releases, and review Composer and npm packages for anything abandoned, badly outdated or with known security issues. Upgrade paths are noted with a rough sense of effort.
Critical paths
We trace the two or three flows the business relies on, such as sign-up, checkout, booking or reporting. We follow each one through routes, controllers, models and queries, and note where logic is fragile, duplicated or untested.
Security and data risks
We look for common problems: exposed secrets, missing authorization checks, unsafe mass assignment, unvalidated input, weak password or session handling, and anything that could leak or corrupt data.
Code structure and maintainability
We do not grade style for its own sake. We look at whether a new developer could make a change safely: how logic is organised, whether there are tests, how errors are logged, and how deployments happen.
Hosting and deployment
We review how the app is deployed, how queues and scheduled jobs run, whether backups exist, and what happens when something fails at night.
What you get at the end
You receive a written report in plain language, not a wall of tool output. It includes:
- A summary of the current state and the biggest risks.
- A prioritised list of issues, marked by severity and rough effort.
- A clear recommendation: stabilise and improve, partially rebuild, or replace.
- A suggested first sprint if you want to keep going.
The report is yours to keep. You can use it with us, with your own team or with another developer.
What happens after the audit
If you want us to carry on, the usual next step is a fix sprint at $1,000, with half paid up front. A sprint takes the highest-priority items from the audit and works through them, starting with whatever blocks the business today.
There is no obligation to continue. Some teams take the report and handle the work internally, and that is a perfectly good outcome.
What we need from you
To start, we need read access to the repository, a short description of what the app does and what is going wrong, and, if possible, access to a staging environment or a sanitised database dump. We do not need production write access for an audit.
Get a clear picture first
If your Laravel app is stuck and you are not sure whether to fix it or start over, start with evidence. Book a 48-hour rescue audit and get a written plan before you spend on a rebuild. You can read more about how we approach stalled projects on our software rescue page. Or contact us to talk it through.