Skip to content

Service

Maintenance and support for Laravel applications

Going live is where the longer part starts. Dependencies want updates, requirements shift, and sooner or later somebody asks why this used to be faster.

Why maintenance is not a side issue

A web application stands in the open internet and consists in good part of somebody else’s code. Every package can have a hole, and the advisories about them are public. Skip regular updates and you accumulate arrears. At some point the jump is so large that nobody wants to make it on the side any more.

The second reason is less dramatic and costs more money all the same. Applications nobody looks after go quiet slowly. A queue that has not run for weeks. An export that comes back empty. A certificate that expires. In house, that sort of thing usually surfaces only when somebody outside complains.

What monitoring is supposed to do

A dashboard nobody looks at is not monitoring. It becomes useful when it speaks up exactly when somebody has to act and stays quiet otherwise. We watch a few signals that actually say something. Is the application reachable? Is the error rate climbing? Are background tasks being worked off? Is storage filling up?

Alarms that fire constantly get ignored by everyone after a fortnight. So adjusting the thresholds is part of the ongoing work and not a one-off setup.

Backups that deserve the name

Almost everyone has backups. Whether a working system can be restored from them is something far fewer people have tried. That is the only test that counts. We restore backups regularly into a separate environment and check whether the application comes up there.

Two findings keep recurring. The database is backed up and the uploaded files are not. Or the backup sits on the same server as the application.

Four stations arranged in a circle: watch, report, update and verify, joined by arrows running clockwise. In the middle it says keeps running, incident or not.
Maintenance is a cycle, not an appointment. Watch, report, update, verify. The point is that none of it is noticeable — apart from the message when somebody really does have to act.

In detail

What we take on

  • Security updates

    Keeping an eye on dependencies and putting fixes in promptly. One big jump a year is the more expensive option.

  • Version care

    Keeping Laravel and PHP on maintained releases. Small steps taken regularly cost less than rare large ones.

  • Monitoring

    Availability, error rates, response times, queues. We would rather not learn about a problem from your phone call.

  • Testing the backups

    A backup that has never been restored is an assumption. We test the way back, not merely whether files are there.

  • Small changes

    One more field, an adjusted report, a new recipient on a list. None of that is worth a project, and somebody still has to do it.

  • Named contacts

    Your mail reaches people who know your application. Not a ticket system that eventually produces an answer.

More services

You may also need

FAQ

Questions about maintenance and support

Do you maintain applications you did not build?
Yes, and it is often how things start. A code audit comes first, so that we know what we are taking on. After that we say plainly whether we can be answerable for the application as it stands or whether something has to happen first.
What happens when something is urgent?
We put availability and response times in writing, so that both sides hold the same expectation. What we do not do is promise round-the-clock cover we could not keep up permanently.
Does this run on a fixed allowance?
Usually yes, because it lets both sides plan. The size follows from how large and how critical the application is. We look at what actually comes up rather than selling a package that does not fit.
Can we take maintenance back in house later?
Yes. We document so that a handover is possible, and we accompany it when the time comes. Maintenance that only works because nobody else can see through it would leave you with all your eggs in one basket.

Is your application running without anyone looking after it?

Then it is worth a look at its condition, before the first incident provides the occasion.