InspectLegacy PHP / Laravel
What this package is
This package does not change a single line of code. It is what makes everything after it possible to price honestly. I read the whole system, map what is where, point out the risks and the security holes I find, and tell you plainly whether it is worth building on or worth replacing, with reasoning you can check.
The reason this step exists is purely about price. What follow-on work costs depends entirely on the state of the existing code. Anyone quoting without having seen it has to price in the risk, which means you pay for that padding even when your code turns out to be fine. Inspecting first makes the quote match the real work. And if you go ahead, I take this fee off the next piece of work in full.
What you get back is a report you can hand to somebody else. It is not written to be useful only to me. If you read it and decide to hire another developer, it works just as well for them.
See it working
| System | Internal order desk · Laravel 6 · PHP 7.2 |
|---|---|
| Size | 412 PHP files · 38 tables |
| Inspected | 5 Aug 2026 · 4 days |
| Verdict | Build on it, do not replace it |
01 Code health check
The structure is readable and the business logic inside it is correct. What makes it untouchable is that there is not a single test anywhere, not that the code is bad. So I do not recommend a rewrite. Rewriting throws away six years of proven logic and restarts the bug count at zero. Three things should happen, in this order.
- ImmediatelyMove PHP to a supported version. 7.2 went end of life in 2020, so nothing published since then can be patched.
- Before changing anythingWrite tests around receipts and stock deduction. If either breaks, nothing can be sold all day.
- When convenientFix the reporting query that pulls whole tables to count them in PHP. That is the 31 seconds.
02 What was found, most important first
No tests anywhere in the system
Whole project, no tests/ directoryCriticalNothing tells anyone what a change broke, so the next person has to guess. This is why your team has not touched it in two years.
How to fixWrite tests around the paths that must not break first: receipts, stock deduction, discount calculation.
PHP 7.2, end of life since 2020
composer.json line 14HighVulnerabilities published since then have no patch, and the list of them is public reading for anyone.
How to fixStep to 7.4 then 8.1 with tests confirming each step, rather than one jump.
Database password committed in the code
config/database.php line 42HighAnyone with repository access sees the live database password, including everyone who ever had access.
How to fixMove it to configuration outside the repository, and rotate the credentials, since they must be treated as leaked.
The full report carries 14 more items, plus time and cost for the work you asked about.
This is an abridged sample. The figures and the system name are invented, but the format, the headings and the way it is written are exactly what a real client receives.
Everything you get
This list is the entire scope of the package. Nothing is hidden in a contract.
- I read the whole structure and write you a map of it
- Risks, technical debt and security holes, listed with severity
- A straight answer on whether to extend or rewrite, with reasons
- A real quote for the work you want, based on code I have actually seen
- Fully credited against the next job if you hire me for it
- Rewriting the whole system in a different stack. If the check says a rewrite is genuinely the right call, I will say so and quote it as new build work rather than folding it into maintenance.
- WordPress plugin and theme work. That is a different discipline from Laravel and I do not take it on right now.
- Recovering a system that has already been compromised. That has to be scoped case by case, because the blast radius differs enormously.
- Server and third-party service costs. Those go straight to the provider and I tell you the numbers before you commit.
Questions about this package
What does the report actually look like?
It is written so a non-developer can follow it. A one-page summary of the state of the system and what to do about it, then the detail item by item, each pointing at the real file, ranked by what matters most. It ends with time and cost for the work you said you wanted. There is a full sample on this page.
What if the report says not to hire you further?
Then we stop there and I consider the job a success. You paid a small fee to avoid spending a great deal on work that should not happen. The report is still yours and you can hand it to anyone. Nothing in it is locked to me.
How do I know you will not push a rewrite to win a bigger job?
You can check that in the report itself. Every conclusion has to carry its reasoning and point at real files. Weak reasoning is visible. I also always write down the cheapest option available to you, even when that option means less work for me.
Is it really 4 days?
Yes, four days counted from the day I can reach the code, not from our first message. If the system turns out to be much larger than usual, I tell you before starting with a new number, rather than going quiet and delivering late.
How many years of Laravel do you have?
Plainly: my main stack is TypeScript and Python. For Laravel I would rather prove it with something you can inspect than count years. GradeLens, a school grading system, is written in Laravel with the whole codebase open to read, a test suite, and a live login you can try from the work page. If you read the code and decide it is not up to your standard, I would rather you judged it that way. A year count tells you nothing when the code is right there.