What a code audit actually finds

The question comes up often enough to be a pattern. A founder or whoever inherited the code has a half-built product that has to ship, and they want to know what is actually there and what it would take to get to production. The timeline they have in mind rests on an estimate that was made before anyone looked closely at the code.

Almost none of those assumptions survive contact with the actual code.

A code audit is the only reliable way to find out where things stand before committing to a build path.

What “almost done” usually measures

When a codebase is described as nearly complete, the person making that assessment is typically measuring features that have code written for the happy path. A screen exists and a button does something. The demo works when you click through it in the right order, with clean data, in a controlled environment.

That is not the same as the work required to ship a production-ready product. The gap between those two definitions is where most project delays live.

The missing pieces are predictable. Error handling and edge cases are never built until someone forces the issue. Tests were skipped to move faster. Deployment infrastructure does not exist. The codebase was built with clean fixtures, so real data handling was never addressed. Security and permission logic is half-built. Integration work that connects all the pieces was deferred to the end, because it cannot begin until the pieces exist.

Each of those categories is real weeks of work. None of them appear in a feature count.

What a code audit covers

A code audit takes one to three weeks and costs $4,000 flat. We need access to the code and whatever documentation came with it, and that is the whole list. We read the code and send back a written report.

The report covers what was actually built versus what was scoped, what the deployment setup looks like, whether tests exist and what they cover, where the security gaps are, and what undocumented decisions are embedded in the code. A code audit is a factual assessment of where the project stands. Pricing the remaining work comes after that, once the scope is known.

Clients sometimes resist this step because they want to start building. The alternative is making decisions based on an estimate that was made without looking at the code, and that is how timelines slip.

The hardest thing to recover is undocumented intent

Every codebase contains hundreds of decisions that look arbitrary until you understand why they were made. Why does this logic live here instead of one layer down? Why does this database table have the shape it has, and why does this API call fire at the point it does?

Whoever wrote the code made those decisions, and they held the answers in their head. Without documentation, the audit team reconstructs that reasoning from the code itself, one inference at a time. Reading intent out of code is slower than writing code from intent.

On a well-documented project it might take two weeks to get a complete picture. On an undocumented codebase it can take four to six weeks. That time is not wasted. It is the cost of missing documentation, and it is rarely in anyone’s mental budget when they want a quick assessment.

The audit report captures those recovered decisions so they are not lost again.

What a realistic timeline looks like

A codebase that looks 80% done will almost never ship with 20% of the remaining effort. Once an audit, remediation of hidden gaps, and documentation work are factored in, the realistic additional effort is typically 50 to 100 percent of the original scope. Sometimes more.

In most codebases we have reviewed, the first thing discovery surfaces is scope that someone deferred and never wrote down. Error handling was left for later. Validation logic was skipped. A third-party integration was mocked rather than built against the real API. Each item looked small in isolation. Collectively they represented weeks of unaccounted work. All of it lands on whoever picks the project up next.

When starting over makes more sense than continuing

Continuing from an existing codebase is almost always the right call, even when the code is messy. Rewrites take longer than expected and reintroduce every problem the original team already solved. Working code, even imperfect code, encodes decisions that someone already got right.

The cases where starting over is worth serious consideration are narrow. A stack that cannot support what the product actually requires is one. So is a data model wrong in ways that patching cannot correct. The clearest signal is an audit that finds more of the codebase getting replaced than kept. In those situations, continuing means rebuilding piece by piece while calling it a continuation. That costs more and takes longer than an honest rewrite.

That decision belongs in the audit report rather than in the first conversation. Nobody can answer it honestly before reading the code.

What to bring to a code audit

The most useful thing before commissioning a code audit is to gather everything the build produced. That means the code, plus any documentation, design files, requirement notes, and deployment credentials that still exist. The more context the incoming team has, the faster the report comes back.

The second most useful thing is to arrive without a fixed conclusion about what comes next. An audit produces a clearer picture than any estimate made before the code was read. What matters in practice is whether the original scope counted features planned or features ready to ship. Those are different standards with different answers. The distance between them is usually where the next several months of work are hiding. If you are weighing whether to continue or rebuild, a code audit is the right first step.