Laravel Maintenance & Support

Most Laravel applications are maintained by whoever built them, until that person leaves. What follows is familiar: nobody upgrades anything because nobody is sure what will break, the dependency list ages quietly, and the first real problem arrives at the worst possible hour with nobody who knows where the bodies are buried.

This is the arrangement that prevents that, for businesses whose application is important but does not justify a permanent Laravel team.

What it covers

Security patches, applied promptly. Laravel, PHP and your dependency tree all publish advisories. Most are irrelevant to you and a few are not, and knowing which is which is the work. Patches within the supported range go out on a schedule; anything urgent goes out when it is disclosed rather than at the next convenient release.

Dependencies kept installable. The expensive failure is not an outdated package - it is discovering, on the day you need to add something, that nothing new will install because the constraints no longer resolve. Keeping that graph healthy is a small monthly task and an enormous one-off project.

The framework kept in support. A minor upgrade each time one lands, and a major upgrade planned rather than deferred. The difference between an application one version behind and one three versions behind is not three times the work - it is the reason upgrades and rescue exists as a separate engagement.

Somebody on the other end. A route to an engineer who already knows your schema, your queues and your deployment, so an incident starts with diagnosis rather than with orientation.

Monitoring that means something. Failed jobs, queue depth, error rates and the endpoints that carry money - watched, with thresholds agreed with you, so the first report of a problem is not a customer.

What it does not cover

New features. This is deliberate rather than mean: a retainer that absorbs feature work turns into a slow, unplanned development budget, and the maintenance stops happening because features are always more urgent. Feature work is quoted as feature work, and the two do not compete for the same hours.

How it runs

We start by reading the application, whether or not we wrote it - the dependency graph, the deployment path, the jobs, the integrations and whatever has been keeping people awake. That produces a short document: what is fragile, what is out of support, and what would happen at three in the morning.

After that it is a monthly rhythm. Patching and updates go out on a schedule you know in advance. Anything urgent interrupts it. Each month closes with a note saying what changed and what is coming, which is the document your auditor asks for and the one your next developer will be glad exists.

Everything happens in your repository, as reviewable pull requests. Nothing is done to your system that you cannot read afterwards.

When this is the wrong thing to buy

If the application is already several versions behind and difficult to change, maintenance is not the starting point - the upgrade is, and pretending otherwise means paying monthly to hold a position that keeps getting worse.

If nobody can say whether the application is healthy, the audit answers that in two weeks for a fixed price, and the answer decides which of these engagements you actually need.

What you receive

A monthly written note: what was patched, what was upgraded, what we chose not to touch and why, and the hours used against the hours booked. The work itself arrives as pull requests, and anything that goes wrong gets a write-up longer than a line in a chat window.

The first month also produces a short inventory of the application. Versions, dependencies with known problems, and the three things most likely to wake somebody up. That document is useful to you whether or not the arrangement continues.