Service
Laravel consulting and code audit
Sometimes the question is not who builds a thing but whether the chosen route holds. For that you need someone with nothing to sell.
Software audit or code audit
The two terms get used interchangeably and mean different amounts. A code audit looks at how the application is written: structure, readability, the state of the tests, obvious weaknesses. A software audit asks beyond that about everything belonging to the application that is not in the code — licences of the packages in use, rights to the source, dependence on individual people, the condition of hosting and backups.
For a takeover or a check before a purchase, you need the second. Before a larger extension the first is usually enough. We settle beforehand which question is to be answered, because scope and price follow from it.
Typical occasions
Hardly anyone commissions an audit out of curiosity. There is usually a concrete occasion. An application is to be taken over and nobody knows what is inside it. A project is running late and the explanations have stopped convincing. A company is being bought and the software forms part of the review. Or a larger extension is coming up and it should be clear beforehand whether the foundation carries it.
In all four cases it helps to have a look from outside that has nothing to prove to anyone.
What an audit is not
An audit is not a line-by-line reading. Nor is it an automated scan with a hundred formal remarks. We use tools, but they deliver raw material and not a judgement. The value appears where somebody weighs up which finding really counts in your case and which is noise.
A recommendation to rebuild rarely comes out of it here. That answer is comfortable and usually wrong. There is nearly always a route that keeps using what is already there.
What you get
You get a report that somebody who does not write code can read. For every finding it says what was found, why it counts and roughly what fixing it costs. Sorted by what we would take on first.
With it comes a conversation in which we go through the report. What you do with it afterwards is your business. If you want support putting it into practice, you will find it under maintenance and support or migration and upgrades.

In detail
What we look at
Architecture
Does the cut hold up? Does the logic sit in sensible places, or has everything gathered in a few enormous classes?
Dependencies
Which packages are out of date, which are no longer maintained, which carry known vulnerabilities.
Security
Permissions, input validation, file uploads, configuration, credentials. The layer with the most findings.
Database
Missing indexes, queries inside loops, data models that make every report expensive.
Tests and deployment
Is there a safety net for changes, and can a given state be rolled out reproducibly?
The result
A report of findings, each with a severity and an effort, sorted by what we would tackle first. It is explicitly not a quotation.
More services
You may also need
Laravel development
Custom applications, from the first workshop to day-to-day operation.
APIs & backend development
Stateless REST and JSON APIs behind web front ends, apps and other systems.
Migration & upgrades
Version jumps, replacing legacy systems, moving onto Laravel.
Maintenance & support
Updates, monitoring and a named contact for applications already running.
FAQ
Questions about the audit
What do you need from us?
Will our current supplier find out?
Do we get a quotation from you afterwards?
What if the answer is that everything is fine?
Want a second opinion?
Tell us what is being argued about. We will tell you whether an audit can answer the question at all.