Laravel Audit

An audit exists for one situation: you have an application, something about it worries you, and the next decision costs more than finding out would.

It is fixed-price and fixed-scope. Two weeks, a written document, and no obligation at the end of it.

What we look at

The data layer. Schema, constraints, indexes against the queries that actually run, the migrations that would be dangerous on your row counts, and the query count on the endpoints that carry traffic.

Background work. Every job and scheduled task, what happens when each one fails, whether any of them are unsafe to run twice, and whether a failure reaches a human.

The request path. Where time goes on the endpoints that matter, what is being done synchronously that should not be, and which third parties can take the application down with them.

Security, at the level an application audit can reach. Authorisation enforced in policies rather than assumed by routing, mass assignment, the handling of secrets, dependency advisories, and whether the negative cases are tested. This is not a penetration test and we say where the boundary is.

Upgrade exposure. How far behind the framework and PHP are, which dependencies are abandoned, and what the path forward costs.

The things that decide the next year. Test coverage where it counts, whether the deployment is repeatable, whether anyone would notice an incident before a customer reported it, and how much of the system's behaviour exists only in one person's memory.

How it runs

Send the repository and a way to run it. If somebody knows why the awkward parts are the way they are, half an hour with them is worth more than a week of reading.

The price is fixed and agreed before we start, written into a short scope that says what we will read and what we will not. It does not move if the application turns out to be worse than expected. An audit that gets more expensive the worse the news is is not one you can trust.

A week to ten days later you have the document. We walk through it with you once, and after that it is yours to act on, with us or without us.

What you get

One document. Every finding has the same four parts: what it is, where it is, what it will cost you if nothing changes, and what fixing it involves. Ranked by expected impact rather than by severity label, because "critical" on a code path that runs twice a year is not the thing to do first.

Alongside it, a schema and route inventory - frequently the first complete map of the application anyone has had.

No slide deck. No score out of ten. A score is a way of summarising findings for people who are not going to read them, and the people who need this are going to read them.

What it is not

It is not a sales document with a proposal at the end. The findings are written to be handed to your own team, and several clients have done exactly that.

It is not a rewrite recommendation. If a rewrite is genuinely the right answer we will say so with the cost of both options beside each other, but it is the answer far less often than it is proposed.

It is not a list of style opinions. Whether your codebase uses repositories or actions is not a finding. Whether a payment can be captured twice is.

When to buy one

Before an acquisition, on either side. Before committing a quarter to a rewrite somebody has proposed. When the team that built it has left. When something broke in production and the explanation nobody liked was "we are not sure why it worked before". Or when you simply want a second opinion from someone with no stake in the answer.

If the audit finds that the work is performance, or the database, or an upgrade, it says so and sizes it. If it finds nothing much, it says that too.