FixLegacy PHP / Laravel
What this package is
This is the package where the work actually happens. Bugs fixed from an agreed list, features added within a scope written down before anything starts, and the slow parts made faster with before and after numbers you can see, rather than a claim that it feels quicker.
What always comes with this work is a test suite covering what I touched. This matters more than it sounds. The reason an old system becomes untouchable is rarely that the code is bad. It is that nothing tells you what a change broke. Once the tests exist, the next person to open it, including your own team, knows within seconds.
The health check is included here, so there is nothing to buy separately. If you already bought Inspect, I take it off in full.
See it working
| Scope | 6 bugs fixed · 2 features added |
|---|---|
| Duration | 14 days · delivered in 4 stages |
| Code | 23 pull requests merged into your repository |
| Status | Delivered in full |
01 Handover summary
Everything on the agreed list is closed, and everything touched is covered by tests. Where something can be measured, both the before and the after are here to compare, rather than a claim that it feels faster.
- ClosedAll 6 bugs, including reports coming up short in 31-day months, outstanding for two years.
- AddedPer-person sales totals and Excel export, to the scope written down before the work began.
- Your team can carry it11 pages of handover documentation and 34 tests they can run with one command.
02 Before and after
| Screen | Before | After |
|---|---|---|
| Monthly report page | 31.4s | 1.8s |
| Customer search | 4.2s | 0.3s |
| Issuing a receipt | 2.1s | 1.9s |
03 Tests added
| Receipts and tax calculation | 12 |
| Stock deduction and returns | 9 |
| Discounts and commission | 8 |
| Roles and sign-in | 5 |
The full document lists the commits item by item, and how your team runs the tests themselves.
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.
- Includes the code health check
- Outstanding bugs fixed, from a list we agree on first
- New features built to a scope written down before I start
- Tests around everything I touch, so the next change does not undo this one
- Query and index work on whatever is slow, with before and after numbers
- Handover docs your own team can read and continue from
- 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 if a fix breaks something else?
That is why tests go around the area before I touch it, and why work ships in stages you see before I continue. Anything broken by my work I fix free during the warranty period. Things that were already broken before I arrived and sit outside the agreed scope are quoted separately, always before the work.
I only have one bug. I do not want to commission all this.
That is fine. Single fixes are priced separately, starting at a small fixed fee per issue, and that includes reading enough of the surrounding code to understand it before changing anything, plus a test covering that spot. Not just making the symptom go away. Describe the symptom and I will price it.
Can you work alongside our own developer?
Yes, and I prefer it. I work through pull requests your team reviews, and leave documentation and tests they can carry on from. The aim is that your team does not need me indefinitely, not that you are tied to me.
Why not just rewrite it and be done?
Because a system that has run for years has correct business logic buried in it that is usually written down nowhere else. A rewrite throws away the part that is proven and restarts the bug count from zero. I propose a rewrite only when inspection shows that building on it genuinely costs more, and when I do, it is quoted as new build work, not folded quietly into maintenance.
How does payment work?
In stages tied to work you have seen, not to time passing. The code is in your repository from day one, so progress is visible throughout rather than a surprise at handover.