Insights · 11 min read
What a software code audit actually checks, what it costs, and how to use the findings before you buy a software company, invest in a startup, or inherit a codebase.
By GGP Editorial
Buying a software business, investing in a startup, or inheriting a codebase someone else built all come down to the same question: is the code worth what the deal says it is worth? A polished demo cannot answer that. Only a technical review can.
We run code audits and technical due diligence for founders, acquirers, and investors. Most come in with the same worry: they cannot read the code themselves, and they are not sure the seller's claims hold up. This guide explains what an audit checks, what it costs, how long it takes, and what to do with the results. It is written for buyers, not for engineers.
You do not need an audit for a greenfield project where your own team writes every line. A code audit earns its fee in a handful of specific situations.
You are acquiring a software company or a product. The code is the single most important asset in the deal, and it is the one buyers understand least. A review tells you whether the revenue depends on clean, maintainable code or on one person who patches bugs at 2 a.m.
You are investing in a startup. Seed-stage investors do not always need a full audit, but a technical review before a larger round catches claims that the product "scales" when it actually runs fine with three customers and falls over at three hundred.
You are taking over an existing codebase. This happens when you hire a new team, switch vendors, or bring development in-house. Before anyone writes new code, you need to know what the existing code can safely support. It is a common step right before a legacy system modernization project.
You are about to sign a large build contract. If a vendor has already built part of the system and you are about to pay for the next phase, an independent review of what exists is cheap insurance against paying twice for work that needs redoing. The review belongs in the same conversation as your software development contract.
In each case the goal is the same: replace guesswork with evidence before money changes hands.
A serious audit is not a style review. It looks at whether the software will keep working, keep scaling, and keep the business safe. The exact scope varies, but these areas are standard.
Architecture. How the system is put together, and whether the parts are separated in a way that lets a team change one thing without breaking three others. A monolith can be fine at small scale and a liability at large scale; the audit tells you which one you are looking at.
Code quality and maintainability. How hard it is for a new developer to understand and modify the code: naming, structure, duplication, dead code, test coverage. Bad code does not always mean the product fails. It means every future change is slower and riskier.
Security. This is where the expensive surprises live. Authentication, authorization, how secrets are stored, how inputs are handled, dependencies with known vulnerabilities, how the system handles user data. A security finding can turn a profitable acquisition into a liability.
Scalability and performance. Whether the current design holds up as users and data grow. Bottlenecks in the database, missing indexes, queries that work in staging and time out in production.
Data model. How information is stored and related. A confusing data model is one of the hardest things to fix later, because every feature is built on top of it.
Dependencies and licenses. What third-party libraries the code relies on, whether they are maintained, and whether any licenses create obligations. Abandoned dependencies are a common source of security risk.
Infrastructure and deployment. How the software gets built, tested, and shipped. Manual deployments, no staging environment, no rollback plan: these are process risks that cost real money in an incident.
Documentation and handover. Whether a new team could realistically take over. A system with zero documentation and one key developer is a single point of failure, not an asset.
A good audit ranks findings by severity instead of handing you a wall of complaints. You need to know which issues block a deal and which are just annoying.
People use the two terms together, but they are different scopes.
A code audit is a deep look at the code itself. It answers "is this code any good?" It usually produces a technical report with findings ranked by severity.
Technical due diligence is broader. It reviews the code, but also the software architecture, the team's process, the security posture, the infrastructure, and whether the technology choices fit the business plan. It answers "can this product do what the seller says it can, and what will it cost me to keep it going?"
For a small acquisition, a code audit may be enough. For a company purchase or a large investment, you want full technical due diligence. The difference in cost reflects the difference in depth.
Certain findings show up often, and they matter more than others.
One person holds the whole system. There is no documentation, and a single developer knows how everything works. The code may be fine, but the risk is concentrated in a person who can leave. That changes what you should pay and how you should structure the transition.
The code does not match the demo. Sometimes the version you were shown is not the version in the repository. An audit that compares the deployed product against the claimed features catches this quickly.
Security problems in core flows. Hardcoded credentials, no rate limiting on login, user data stored in plain text, dependencies with critical known vulnerabilities. These are not cosmetic; they can create legal and financial exposure the moment you own the product.
Scaling claims are untested. A product that works with a few customers may collapse under load because of a single slow query. The audit estimates where the breakpoints are.
Technical debt is concentrated, not scattered. A little debt everywhere is normal. A lot of debt in the one module that generates all the revenue is a negotiation point.
The point of surfacing these is not to kill the deal. It is to price it correctly. A buyer who knows the cost to fix an issue can adjust the offer instead of discovering it after closing.
The audit moves faster and costs less when the reviewer gets the right inputs up front. Ask for these before you commit to a price.
Source code and commit history. The full repository, not a zip file of the current state. Commit history shows who built what, how often, and whether the "team of ten" in the pitch deck was actually two people.
Access to a running environment. A staging or demo environment lets the reviewer see behavior that is hard to read from code alone. Production access is usually not necessary and adds risk.
Architecture documents and diagrams, if any exist. Their absence is itself a finding.
A list of people to interview. For technical due diligence, conversations with the lead developer, the DevOps person, and the product owner reveal more than the code does.
A clear list of the seller's claims. What revenue, what scale, what uptime, what features. The audit checks the code against those claims, so write them down first.
Audit pricing depends on three things: the size of the codebase, the depth of the review, and how much infrastructure you want checked.
As a rough guide, most projects we see fall into these bands.
| Scope | What it checks | Typical cost range |
|---|---|---|
| Code review (light) | One app, focused look at structure and obvious risks | $3,000–$8,000 |
| Full code audit | Multiple services, code quality, security, data model, dependencies | $8,000–$25,000 |
| Technical due diligence (acquisition) | Everything above, plus architecture, process, infrastructure, and team interviews | $25,000–$60,000+ |
These ranges are indicative, not quotes. A 50,000-line single app is a different job from a distributed platform with eight services and two mobile apps. Line count is the biggest driver, but so is depth: a security-focused review costs more than a readability review because it takes more senior people and more time.
Two things to keep in mind. First, the cheapest audit is usually not the best value. A review that finds nothing because it did not look hard enough costs you the fee plus whatever it missed. Second, the fee is small next to the deal it protects. If a $40,000 review surfaces a $300,000 remediation problem, the review paid for itself before you even negotiate.
Expect a fixed price for a defined scope. If the scope is vague, expect a short discovery step first so the quote reflects the actual codebase rather than a guess. This is the same discipline that applies when you estimate a custom software project.
A light review of a small codebase can take a few days. A full audit of a mid-size system usually takes two to four weeks. Acquisition due diligence can run a month or more, because it involves interviews and infrastructure review on top of the code reading.
At the end you should receive a written report, not a phone call. It should include a summary a non-technical buyer can read, a list of findings ranked by severity, the estimated effort and cost to fix the important ones, and a recommended path forward.
Some teams stop at the report. The report is only half the value. The other half is the conversation where you ask questions and the reviewer explains what actually matters for your deal. Make sure the price includes that conversation.
The report is most useful at three points in the process.
Before closing, you use it to negotiate. A finding that will cost $80,000 to fix is a reason to adjust the price, ask the seller to fix it first, or hold back part of the payment until it is fixed.
After closing, you use it as a remediation plan. The severity-ranked list becomes the backlog for your first quarter of ownership. You fix the security issues first, then the scaling risks, then the maintainability debt.
If you walk away, the report tells you why. That is still money well spent. A clear "no" backed by evidence is cheaper than a bad deal.
One note on vendors. You want the audit done by engineers who build and run systems in production, not by people who only review code for a living. A reviewer who has shipped software and fixed the exact problems they are flagging can tell you what a finding actually costs, which is what you are really paying for. If the audit leads to a rebuild, the same logic applies when you decide between building and buying.
Do I need technical due diligence for a small acquisition?
Usually a full code audit is enough. Full technical due diligence matters more when the product is complex, the deal is large, or the technology is central to the business.
Can a code audit find everything?
No. An audit samples and prioritizes. It catches the issues that matter most, but no review is a guarantee. What it removes is blind risk, not all risk.
Who should commission the audit, the buyer or the seller?
The buyer, and the reviewer should be independent of the seller's team. An audit paid for by the seller has a conflict of interest built in.
How much code can a reviewer cover in a week?
It depends on depth, but an experienced reviewer working at real depth can cover a few tens of thousands of lines in a week. Bigger codebases need either more time or a sampling approach.
What if the audit finds serious problems?
That is the system working. You now know the true cost of the asset. You can renegotiate, ask for fixes, or walk away with evidence. The worst outcome is finding out after the deal closes.
If you are buying software, investing in a product, or inheriting a codebase, an independent technical review is the cheapest insurance you can buy on the deal. GlobeSoft's engineers build and run production systems in Java, Spring Boot, Node, Go, Python, and React, so we can tell you not just what is wrong but what it will cost to fix.
Tell us what you are building and where you are today. We typically reply within 24 hours.
