Code review and architecture audit

What this actually solves

Three situations bring people here and they look different from the outside, but they are the same purchase underneath.

The first is an owner who paid an agency to build something, watched the agency move on, and has now hired a developer who says the whole thing needs rewriting. The owner has no way to tell whether that is an honest engineering judgement or a new person who would rather start clean than read someone else's work. The second is a CTO who has been saying the same thing internally for three months and cannot get the budget, and needs an outside voice to say it in a document that a board will read. The third is someone about to buy or invest, who needs a lighter version of due diligence before committing.

In all three cases you are buying one defensible sentence you can put in front of somebody else. Not a list of observations. A verdict, with the reasoning attached, that survives being argued with by the person who wrote the code. That is a different product from a code review inside a team, and it changes how the work is done and how it is written up.

The two halves of the name matter too. A code review is the close view — files, functions, patterns, the specific line where a token is logged. An architecture audit is the wide view — which components exist, how they talk, what is exposed, and which big decisions have already boxed you in. Systems fail in both directions, and looking at only one of them is how an audit misses the thing that actually takes the site down.

What we do, and in what order

1. Scope and read-only access. Which repositories, which environments, what is explicitly out of scope, and a written undertaking that nothing will be modified. This is agreed before a single file is opened. Half a day.
2. The automated pass. Linters, static analysis and dependency auditing, plus cloc for a first map of size and language mix and git log for where change actually concentrates. Semgrep for security patterns, ESLint or Ruff depending on the stack, npm audit or pip-audit for dependencies, SonarCloud for a quality overview. This is not the work. It is the first page of the work, and your own team could run it. Half a day to a day.
3. The structural pass. A module map, and then an architecture diagram drawn by hand in Excalidraw or Mermaid — what calls what, where data is stored, what is reachable from the internet, where configuration and secrets are read from. Drawing it is not decoration. Until the diagram can be drawn, the system has not been understood, and the places where the pen stops are usually the places worth investigating. One to two days.
4. The manual pass on five files. Only five, chosen deliberately, read line by line. They are almost always the same three kinds of file — anything touching payment, anything touching authentication, and the old one that everybody on the team refers to as the file nobody touches. Depth on five beats a skim across the whole repository. Two to four days.
5. One hour with the lead developer. The most valuable question in the engagement is what they are most afraid of at night. Tools find patterns; only the person carrying the pager knows which subsystem has been surviving on luck. One hour.
6. Findings, written to a fixed shape. Each one carries a severity of Critical, High, Medium or Low and four fields — what it is, where it is with file and line, what it costs the business if it happens, and how long the fix takes in developer-days with the assumption about developer familiarity stated separately. Anything we cannot tell apart from a deliberate choice goes into a separate list headed questions for the team, not into the findings. Two to four days.
7. Remediation plan and readout. The plan is ordered, not alphabetised, and the readout is a live call where the report is walked through and argued with. Half a day.

What moves the price

The range is $800–$10,000 over 1–4 weeks, and three things decide where in it you sit.

Size and spread. One service of forty thousand lines is a different exercise from a system spread across many services, several languages and a mobile client. Spread costs more than raw line count, because every boundary between components is a place where the interesting failures live.

Who reads the report. A document for your own CTO is a working artefact. A document going to a board, an acquirer or an investor is a different one — every claim has to survive hostile reading, every number has to carry its assumption, and our name and our responsibility sit on it. That difference is real work, not a markup.

Whether the people are available. With an hour of the lead developer's time, access to the git history and a running environment, we can confirm things quickly. Without them, everything has to be inferred from static code alone, which is slower and produces a report full of hedges. If access is going to be limited, we would rather price it honestly at the start than discover it in week two.

What usually goes wrong

The report is hundreds of findings long. You open it, scroll three pages, close it, and do nothing at all. That is the most common way this service fails, and it fails while looking thorough. The point of paying an outsider is to have somebody decide what matters, and a report that refuses to decide has quietly handed the hardest part back. The first page must be an executive summary with no more than five items, each with money or time next to it, and one sentence saying what to do if you only ever do one thing. Everything else belongs in an appendix.

Findings get ranked by how ugly the code is rather than by blast radius. Inconsistent naming, missing formatting, a file that is too long — these are real and they are also what a linter already reports for free. When they appear as findings they bury the three items that could actually take the system down or leak data. Style and formatting are excluded from the report entirely, and every finding that stays has to cite a file and a line. An uncited claim is deleted rather than softened.

Somebody promises a security verdict. The sentence this system is secure is the single most expensive thing that can appear in this kind of document, and the pressure to write it comes from your side of the table, because you want something clean to forward. It is a claim from a different discipline, with its own testing regime and its own liability, and it cannot be supported by a four-week read. What replaces it is narrower and more useful — these specific areas were examined, these specific problems were found, and these areas were not looked at. The same applies to timelines for somebody else's team. We can estimate developer-days with the assumption stated; we cannot promise the date your developers will hit.