Code audit
Know what you have.
Know what to do next.
Get an independent view of the software you already own. We review the code and running system, explain the risks, and give you an ordered plan any developer can use.
For owners and teams who need a clear answer before making another decision.
What you get
A report that helps you make a decision.
The audit reads what exists. It does not change the system or commit you to a rebuild.
An explanation of the system
A review of the code, architecture, running environment, and available documentation.
Ranked risks
A clear view of the issues that matter, including security and the path to release.
An ordered action list
Prioritized next steps that you can hand to your current team or any other developer.
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.
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.
How we approach it
Read first. Report clearly. Let you decide.
We review the repository, running environment, documentation, architecture, security, and release path without changing the system.
Our working processYou 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.
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.
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.
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
What does a standard audit cost?
A standard code audit is $4k flat and takes 1 to 2 weeks. It delivers an independent report, ranked risks, and an ordered action list.
Will the audit change the software?
No. The audit is read-only. We review the repository, running environment, and documentation; changes are separate work.
Do we need to hire you for the fixes?
The report and action list can be used by any developer. You can take the findings to your existing team or decide what to do next.
Will you fix the problems you find?
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.
Why should I pay when other firms audit for free?
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.
Do you do this for codebases in languages you have not worked in?
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.
Is the report confidential?
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.
My codebase is bigger than 50,000 lines.
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.
Can I use the report for investor due diligence?
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.
Will you review a vendor proposal instead of code?
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.
What if the audit says my software is beyond saving?
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.