Code audit
Code audit services from an engineer who is not bidding on the rebuild
You have a codebase and a decision to make. Keep building on it, rewrite it, or walk away. The people best placed to answer that usually want the rebuild contract, which makes their answer worth less. We read the code and hand you a written report, and that is the whole engagement.
A code audit is advisory. We do not take over your project, and we do not quote you a rebuild at the end. Nobody on your team has to sit through interviews. We read what exists and tell you what is actually there.
Independence
We have no stake in the answer
Most code audits are free because they are sales calls. The firm reading your code is the firm hoping to rewrite it, so every finding points the same direction. You cannot separate the diagnosis from the pitch when the same firm wrote both, and only one of the two answers pays them.
We charge for the audit so we do not have to sell you anything after it. If the code is fine, the report says the code is fine and we stop there. If the right move is to keep your current developer and fix a short list of things, that is what you get in writing. We are not bidding on the rebuild, and we put that in writing too.
You can hand the report to your existing developer, to a new vendor, to a board member, or to an acquirer. It reads the same to all of them, because it was not written to win follow-on work.
When it pays for itself
When to get an outside read on the code
You inherited the codebase
The contractor or the developer who built it is gone, and nobody left can tell you what the code does or how much of it is finished.
A vendor quoted a rewrite
Someone told you the existing code has to be thrown away. That may be true. It is also the most profitable thing they could have said.
Due diligence is coming
An investor or an acquirer is going to send an engineer through your repository. You would rather read the findings first.
The build keeps slipping
Every new estimate sounds reasonable and the release date moves again. You want to know whether that is the team, the plan, or the code underneath.
You are about to double down
The next round of spending goes on top of this code, and you want to know whether the foundation holds.
Hiring your first engineer
You need an honest description of what you are asking a new hire to walk into.
Checking a vendor proposal
You have a specification or a vendor proposal and you want to know if the scope, the timeline, and the price line up with the work described.
The deliverable
What is in the report
The report arrives as a PDF, with a one-hour call to walk through it. Every audit uses the same structure, so you can find things and a second reader can follow it without us in the room.
- 01
Summary and the decision
One page. What we found and what we recommend, stated plainly enough to forward to someone who will never read past page one.
- 02
What the system actually is
A plain description of how the software is put together, drawn from the code rather than from anyone's diagram. It describes the system as it stands today rather than as it was planned.
- 03
Architecture assessment
Where the structure holds as you grow and where it gives way, and what it would cost to change the parts that will not hold.
- 04
Code quality and maintainability
Organization, test coverage, dependency health, and how long it will take a new engineer to become useful in this codebase.
- 05
Security and data handling
Vulnerabilities, exposed credentials, permission gaps, and how personal or payment data moves through the system.
- 06
Build and release
How the software gets from a developer's machine to production, what is scripted, what a person does by hand, and what happens when a release goes wrong.
- 07
Risk register
Every finding in one table, ranked by severity and by what it costs the business rather than by how interesting it is to an engineer.
- 08
Recommended actions
An ordered list of what to do. Each item carries a rough effort estimate and the outcome it buys you. You can hand this list to any developer.
Anatomy of a finding
What a single finding looks like
Findings are the unit the report is built from. Every one of them has the same six parts, so nothing arrives as an unexplained complaint about someone else's code.
- Severity
- Critical, high, medium, or low. We rank on business consequence rather than on how much the code offends us.
- Where it is
- The specific files, services, or database tables involved, so a developer can open the right thing immediately.
- What we observed
- The fact, with no interpretation attached. What the code does, quoted or described precisely enough to verify without taking our word for it.
- Why it matters
- The consequence in business terms. What breaks, who notices, what it costs, and how likely it is.
- What to do
- A specific recommendation. Which part of the code, to what standard, and where it sits relative to everything else. "Improve test coverage" is not a recommendation.
- Effort
- A rough size, in engineering days, so you can weigh the fix against the risk instead of guessing.
Findings we cannot back up do not go in the report. If something looks wrong but we could not confirm it inside the scope of the audit, it goes in a separate list of open questions, marked as unverified.
Architecture review
Software architecture review services are part of the audit
Most of the expensive problems in a codebase are not in the code. They are in the shape of the system. A data model that cannot represent your second product line. One service that every other part of the software waits on. Background jobs that nobody still on the team knows how to restart. The same permission check copied into every screen that requires it, which means it is wrong on at least one of them.
A linter will not find any of it, and the damage does not build up gradually. It holds fine until the day you add the feature that breaks it, and by then the fix is a rewrite. So the architecture review is included in the audit rather than sold to you afterwards, and it is usually the part that changes what you do next.
Data model
Whether the shape of your data can carry the next stage of the product, or whether it already requires surgery to hold what you are planning.
Service boundaries
Which parts of the system are separate in fact and which ones only look separate. Where a change in one place forces changes in places you did not expect.
State and consistency
Where the system can end up with two answers to the same question, and what happens to the business when it does.
Scale limits
The specific point at which the current design stops working, expressed in your numbers rather than in general advice.
Reversibility
Which decisions you can still change cheaply and which ones are now permanent. This is usually the most useful page in the report.
Access
What we need from you
- Read access to the repository, or an archive of the code.
- Whatever documentation exists, including diagrams and README files, however out of date they are.
- Access to a running environment if there is one.
- The specification, proposal, or requirements document if you want that reviewed too.
- A short note on the business. What the software is for, who uses it, and what you are planning next.
That is the whole list. We do not run stakeholder interviews or book time with your engineers, and we do not need access to your customers or your other systems. If we have a question, it arrives in writing and you answer when you have a minute.
Price
$4,000 flat
One price, agreed before we start, invoiced once. A standard audit covers a codebase up to 50,000 lines, whatever documentation you have, the written report, and the one-hour walkthrough call.
Larger or unusual codebases get quoted before any work begins, and we tell you the number in the intro call rather than after we have looked around. Nothing about the price depends on what we find.
What is included
- Full review of the code, the architecture, and the release path
- Written report with a ranked risk register and an ordered action list
- One-hour walkthrough call, and you can bring your team or your developer
- Written answers to your follow-up questions after delivery
Most audits are delivered in 1 to 2 weeks from the day we get access, depending on the size of the codebase.
Book a free 30-minute callFAQ
Frequently asked questions
Not as part of this. The audit is advisory and ends with the report. Your team or another vendor does the work. If you later want us to take on some of it, that is a separate conversation and a separate price, and we will say so plainly rather than steering the report toward it.
A free audit is a sales document. The firm reading your code wants the rebuild, so the findings tend to point that way. You are paying us for an answer that is not attached to a proposal. If the correct answer is that your code is fine and you should keep your current developer, we get paid the same $4,000 for saying so.
We tell you before you pay. If we are not the right reader for your stack, we say that on the intro call instead of taking the work and learning on your money.
Yes, and we sign NDAs as a standard practice. Your code, your findings, and your decision to commission an audit at all stay between us. Nothing goes into marketing or a case study without written permission.
Then we quote it separately before starting. Send the details and we will give you a fixed number up front. We do not switch to hourly billing partway through.
Yes. The report is written for a reader who was not in any of our conversations, which is what a diligence engineer is. It stands on its own without us there to explain it.
Yes. We look at scope, sequencing, assumptions, and price against the work actually described, and we tell you what the proposal is quiet about. Reviewing a proposal costs the least before you sign it.
Then the report says so, with the specific reasons and the evidence. That is an uncomfortable report to receive and an inexpensive one to receive early. It is also a report you can trust, because we are not the ones who get the rewrite.
If you want to ask something before booking a call, write to [email protected] and the engineer who would run the audit answers you directly.
Find out what is actually in your codebase.
Thirty minutes on a call. Tell us what you have and what you are deciding, and we will tell you whether an audit answers your question. If it does not, we will say so.
Book a free 30-minute call$4,000 flat. Advisory only. We are not bidding on the rebuild.