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 a Laravel audit looks 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, and what a Laravel audit needs from you

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 from a Laravel audit

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 a Laravel audit 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.

Reading a Laravel application's migrations as its history

The migrations directory is the most honest document in the repository, because nobody writes it to be read.

In order, it is a record of what the business asked for and when. A column added and then never populated is a feature that was abandoned after the schema changed. Three attempts at the same table in one month is a model nobody had agreed. A column added as nullable because the table already had rows, then left nullable for two years, is now a field the application has to defend against being empty in forty places - and the original reason was a deployment convenience in 2023.

The things worth flagging are specific. Foreign keys that were intended and never added, so the relationship exists in Eloquent and not in the database. Enum columns whose allowed values have drifted from what the code writes. Indexes added for a query that no longer runs, and missing for three that do. A down() method nobody has executed, which means the rollback story is theoretical.

It also reveals the migrations that would be dangerous now. A change that was instant on ten thousand rows locks the table on four million, and the schema history tells us which tables grew. That is the difference between an upgrade plan and an outage, and it costs an hour of reading to find out.

What a Laravel audit does with your test suite

Coverage percentage is the number everybody quotes and the least useful one available. A suite can cover eighty per cent of the lines and assert almost nothing about whether the application is correct.

So the questions are different. Which paths that move money or change permissions have a test at all. Whether the negative authorisation cases are tested - not that the owner can see the record, which everybody tests, but that somebody else cannot, which is where the bugs are. Whether the tests that exist would actually fail if the behaviour broke, because a test that asserts a response was 200 and nothing else passes happily through a wrong answer.

Then the suite as an engineering object. How long it takes, because a suite nobody waits for is a suite nobody runs, and eleven minutes is the threshold where people start pushing without it. Whether it needs network access or a seeded database somebody maintains by hand. Whether it can run in parallel, and whether it passes twice in a row - a suite with order-dependent tests is worse than a smaller one that is trustworthy.

The output is not a target percentage. It is a short list of the paths where a test would have caught something the application has already got wrong, which is a list the team can act on in a week.

When to buy a Laravel audit

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.