PHP Code Audit Cost: What a Professional Review Costs in Germany and What You Get for It
Most companies that ask us about a PHP code audit already know their application has problems. What they do not know is what a professional review costs, whether the price is proportional to the size of their system, and what they will actually hold in their hands at the end. This post answers those questions with numbers from the German market, because "it depends" is a useless answer when you have to put a line in next quarter's budget.
We have written separately about what an audit examines and how the review is structured and how to prepare your codebase before the auditor arrives. This post is about the money: PHP code audit cost, what drives it, and how to tell whether you got value for it.
What you are paying for
An audit is not a static analysis run. PHPStan at level 8 will produce a few thousand findings on any application that has been in production for six years, and you can get that list for free in an afternoon. What you pay for is judgement: a senior engineer reading the code, the schema, the deployment pipeline and the test suite, and telling you which of the thousand findings matter, in what order, and what each one will cost to fix.
A full review of a PHP application covers six areas. Architecture, meaning how the code is layered and whether business logic lives somewhere you can test it. Security, from the obvious injection and authentication issues down to how secrets and sessions are handled. Performance, usually dominated by database access patterns. Database design, including migrations, indexes and whether the schema still matches what the application does. Test coverage, and more importantly whether the tests that exist would catch a regression. And the deployment process, because a codebase that can only be released by one person on a Friday afternoon is a risk no matter how clean the classes are.
Each area gets a written finding with a severity, an estimate of the effort to fix, and a recommendation. The report closes with a prioritised list you can drop into a backlog. If a proposal you receive does not describe the deliverable in roughly these terms, ask what you are buying.
PHP code audit cost by application size
Prices below reflect what independent consultants and small specialist studios in Germany charge for senior-level work, in the range of EUR 120 to 200 per hour. Large consultancies charge more and typically staff the work with less experienced people. Offshore providers charge less, and the quality varies more than the price does.
A small application, up to roughly 30,000 lines of PHP with a single database and no separate services, takes three to five working days. Expect EUR 4,000 to 8,000. At this size the auditor can read most of the code rather than sampling it, and the report tends to be very concrete.
A mid-size application between 30,000 and 150,000 lines, with a handful of integrations, a queue, maybe a legacy module nobody touches, takes six to twelve days. Budget EUR 8,000 to 20,000. This is where most Symfony and Laravel systems that have been in production for four to eight years land, and it is the bracket where an audit most often changes a decision, because the team usually cannot see the system as a whole any more.
A large application above 150,000 lines, or anything with multiple services, several databases or a mixed PHP 5 and PHP 8 codebase, runs two to five weeks. EUR 20,000 to 45,000 is realistic, and past that point the engagement should be scoped in phases rather than bought as one block.
Three things push the number up within a bracket. No test suite, because the auditor has to work out behaviour by reading rather than by running. No documentation and no one left on the team who wrote the original code, which turns half the work into archaeology. And a compliance or acquisition deadline, which compresses the schedule and usually adds a second reviewer.
Two things push it down. Good access on day one (repositories, a staging environment that resembles production, database dumps with personal data stripped) and a clear question. "Is this codebase safe to build on for the next three years?" is a scoped question. "Tell us everything that is wrong" is not, and it will be priced accordingly.
Fixed price or time and materials
For an audit, we prefer a fixed price after a short scoping call, and we think you should insist on one. Unlike a refactoring engagement, where nobody can honestly scope six months of work before analysing the code, an audit has a bounded input. The auditor can look at the repository size, the number of dependencies and the schema in an hour and quote a number that is right within 15 percent.
A provider who refuses to fix the price of an audit is telling you either that they have not looked at your system yet, or that they intend to let the engagement grow. Both are reasons to keep looking.
What a fixed price should include: the discovery interview, the automated analysis, the manual review, the written report, and a presentation of the results to whoever makes decisions on your side. What it should not include is fixing anything. Keep the audit and the remediation separate, even if the same company ends up doing both. An auditor who is also bidding on the follow-up work has a reason to find more problems than exist.
What the report has to contain
We have read audit reports from other providers that our clients received before they came to us. The bad ones share a pattern: they are long, they are mostly tool output, and the recommendations are generic enough to apply to any PHP application on earth. "Improve test coverage." "Update outdated dependencies." "Consider adopting a layered architecture." You did not need to pay EUR 12,000 to be told that.
A report that is worth the money has four properties.
Every finding names a location. A file, a class, a query, a config value. If a finding says "several controllers contain business logic," it should list them, and it should say which one to start with.
Every finding has a cost attached. Not a precise estimate, but a bracket: hours, days or weeks. Without it you cannot prioritise, and prioritisation is the whole point.
The findings are ranked against your risk, not against a textbook. A missing index on a table with 400 rows is not a finding. A missing index on the table that your invoicing job scans every night is. The auditor has to have understood what the application is for.
And the report answers the question you actually asked. If you commissioned the audit to decide between refactoring and rewriting, the last page should say which one, with reasoning. We have covered how to make that decision in detail, and a good audit is the input to that framework.
Turning the findings into a roadmap
The report is only useful if something happens afterwards, and in our experience this is where the money most often gets wasted. The PDF gets circulated, everyone agrees it is thorough, and six months later nothing has changed because the findings never made it into the backlog.
The fix is mechanical. Take the prioritised list and turn each item into a ticket with the finding, the location and the effort estimate copied in. Group the tickets into three streams. The first is anything the report marked as a security or data integrity risk, which goes ahead of feature work regardless of what the roadmap says. The second is the structural work that unblocks the rest: usually getting a test harness around the riskiest module, and pinning down the deployment process. The third is the long tail, which gets scheduled alongside features at a fixed share of capacity (15 to 20 percent is common) that never gets dropped to zero.
If the audit recommended a refactoring programme, the report is also your scope document for the next proposal. We have written about what refactoring services cost and how to evaluate a partner; the point here is that an audit done properly makes that next quote far more accurate, because whoever bids on it is no longer guessing.
When an audit is worth it, and when it is not
An audit pays for itself in four situations. Before an acquisition or an investment round, where a third party is going to look at the code anyway and you want to know first. When a team has inherited a system nobody on staff wrote. When the same class of production incident keeps recurring and the team cannot explain why. And before committing a budget to a modernisation programme, because an audit costing EUR 15,000 is cheap insurance on a EUR 200,000 rewrite.
It is not worth it when you already know what is wrong and just need the capacity to fix it. If your lead developer can list the ten worst problems in the codebase from memory, with locations, you do not need someone else to write them down at EUR 150 an hour. Spend the money on the fixes. It is also not worth it for an application that is going to be switched off within a year, unless a regulator or an acquirer is asking for it.
The questionnaire we send before every audit
Before we quote, we send the client a short list of questions. The answers determine the price bracket and, more importantly, the shape of the engagement. We share it here because it is also a reasonable self-check on whether you are ready to commission one.
What is the application for, who uses it, and what happens to the business if it is down for a day? How many lines of PHP, which framework and which version, and which PHP version runs in production? How many databases, external integrations and background processes are involved? Is there a test suite, and does it run in CI on every change? How is the application deployed, and how many people can do it? Who wrote the original code, and are they still available to answer questions? What decision are you trying to make with the results? And is there a deadline driven by something outside engineering, such as a funding round, an acquisition or a compliance requirement?
If you can answer all eight in an afternoon, you are ready. If half of them make you realise nobody on the team knows, that is itself a finding, and it is the strongest argument for doing the audit.
Working with Wolf-Tech
We run PHP and Symfony audits for companies across Germany and the rest of Europe, most often ahead of a modernisation programme, a funding round or a sale. The engagement is fixed price, the report names locations and effort for every finding, and we keep the audit separate from any remediation work so the findings stay honest. Code quality consulting is where that starts. If you want a quote, send the answers to the questionnaire above to hello@wolf-tech.io, or have a look at wolf-tech.io, and we will tell you what the review would cost and whether you need one at all.