Code Audit: What to Check in an Inherited Codebase

A code audit is a structured review of a codebase that tells you what you actually own: what runs, what is risky, and what will cost you money later. When you inherit software from an agency or a departed developer, the audit is the first piece of real information you get.

The order matters more than the tooling. The order I follow for the first 30 days of a takeover is: access first, then the build, then the money paths, then the risks. This article follows that order, so you can run the audit yourself or check whether someone else did it properly.

What is a code audit, and when do you need one?

A code audit reviews source code, infrastructure and operations to answer practical questions. Can we change this safely? Can it lose money or data? What breaks if the one person who understands it leaves? It is not a rewrite proposal and not a judgment on the previous developers’ talent. Many problems come from deadlines and missing budget, not from bad engineers.

Common triggers

• You are leaving an agency, or an agency is leaving you.
• The only developer quit, was let go, or stopped answering messages.
• The app was generated with AI tools and is about to get real users.
• You are planning a migration and need to know what is really in the system.
• You are buying a company or raising money and someone will ask hard questions. That is a related exercise, called technical due diligence.

If everything works, the team is stable and you understand the system, you may not need a full audit. A lighter check of access and backups is still cheap insurance.

Can you get access to everything: repos, hosting, domains, secrets?

Start here, because everything else depends on it. A pattern I watch for in every takeover is code that is fine while a critical asset, such as the domain, is registered under a former contractor’s personal email. That is a business risk, not a technical one, and it can stay hidden until the day a renewal fails.

Make an inventory and confirm that you, as the company, hold owner-level access to each item:

Once you have access, rotate credentials the former team knew. That includes API keys, database passwords and shared logins. This is standard practice after any team change.

Does the project build and deploy from scratch?

This is the first thing I try on any takeover, and it is revealing: on a clean machine, can someone follow the README, run the project locally, and ship a deployment? If the answer is no, you have found a serious problem. A system that only one laptop or one person can deploy is fragile.

Check these points:

1. Clone and install. Does it install with documented commands? Are runtime versions pinned?
2. Local run. Does it need production data or secrets nobody can find? Is there a seed or test database?
3. Tests. Do any exist, and do they pass? A small, trustworthy test suite is worth more than a large broken one.
4. Deploy. Is it automated through a pipeline, or does it depend on manual steps someone did from memory?
5. Environments. Is there a staging environment that resembles production, or does every change go straight to live?
6. Rollback. If a release fails, how do you return to the previous version?

Write down every gap you hit. Also note dependencies that are abandoned, pinned to very old versions, or require end-of-life runtimes. They set the cost of every future change.

Are the money paths (payments, auth, billing) safe?

After the build, review anything that touches revenue or identity. I call these the money paths: payments, checkout, subscriptions, invoicing, login, password reset, and permissions. A bug in a settings page is an annoyance. A bug here costs money or exposes accounts.

I spent time on the cart and checkout team at Total Wine & More, a US retailer with 190 million site visits a year. At that kind of traffic, flaws that look like rare edge cases can show up far more often than you would expect. The lesson I took from it applies at any size: money paths deserve more scrutiny than the rest of the code, however small the product is.

What to review in payments and billing

• Is the payment amount calculated on the server, or can the client send a price?
• Are webhooks from the payment provider verified with a signature, and handled safely if delivered twice or out of order?
• Do you store card data? You usually should not; the provider should hold it.
• Do subscription states in your database match the payment provider?
• What happens when a payment fails halfway through an order?

What to review in authentication

• How are passwords stored and reset? Are reset links single-use and short-lived?
• Are sessions or tokens expired and revocable?
• Does every endpoint check not only who the user is, but whether they may access that specific record?
• Is there a way to find and disable the admin accounts?

Then trace one real transaction end to end, from button click to database row to provider dashboard. It teaches you more than reading files in isolation.

What security issues show up most often?

In inherited projects, the findings are rarely exotic. These are the ones I check first:

• Secrets in the repository. API keys and passwords committed to code or git history. Rotating them is the fix; deleting the file is not enough.
• Missing authorization checks. A logged-in user can read or edit another user’s data by changing an ID in the request.
• Database access rules left open. This is especially common in fast-built apps on managed backends such as Supabase, where row-level security policies must be enabled and written deliberately. The tool is fine; the configuration is what you audit.
• Unsigned or unverified webhooks. Anyone who finds the URL can fake a payment event.
• Outdated dependencies. Known vulnerabilities in packages nobody has updated. Run your ecosystem’s audit command and read the results by severity.
• Overly broad permissions. Shared admin logins, cloud roles with full access, public storage buckets.
• Weak input handling. Unvalidated input reaching queries, file uploads or rendered pages.
• No backups, or untested ones. A backup you have never restored is a hope, not a backup.
• Poor logging and monitoring. Sensitive data in logs, and no alert when errors spike.

This is a practical checklist, not a formal penetration test. If you handle regulated data such as health or payment card information, ask a qualified security firm and your lawyer about your obligations. This article is not legal advice.

What should the audit report contain?

A report that only lists problems is hard to act on. The useful version helps a non-technical founder decide what to do next. I’d expect these parts:

1. Summary. One page: overall condition, the top risks, and a plain recommendation.
2. Access and ownership inventory. What you hold, what is missing, and who must hand it over.
3. Build and deploy findings. Whether the project runs from scratch, and the steps required to fix gaps.
4. Money path review. What was traced, what was found, and what needs urgent action.
5. Security findings. Each with severity, the evidence, and a suggested fix.
6. Maintainability notes. Test coverage, dependency age, code structure, documentation, and the technical debt that will slow future work.
7. Prioritized plan. Things to do this week, this month, and later, with rough effort in relative terms such as small, medium, large.

Be wary of reports that promise exact timelines before the build works, or that conclude the code must be rewritten without showing evidence. In my experience, an incremental path that keeps the product running is usually safer than a full rewrite, which also tends to cost more because the old system must keep running in parallel. When I led the migration of a live job-application platform at avanzzada, we moved the whole architecture to a new stack while people kept using it every day, and doing it piece by piece is what made that possible. Still, that is a rule of thumb, and the audit is where you test it against your real system.

Want a second opinion on your inherited codebase?

If you’re taking over a codebase and want a peer’s view, email me@filipeeduardo.dev with a short description of the situation. I’m glad to take a look and tell you what I’d check first.