How to Take Over an Existing Codebase: A Code Audit Checklist

When you need a code audit

Teams inherit code for many reasons: a freelancer moved on, an agency relationship ended, a company was acquired, or a founder built the first version with an AI app builder and now has paying users. The situation is the same in each case. You are responsible for software you did not write, and you do not yet know what is in it. A code audit turns that unknown into a list: what works, what is dangerous, what will be expensive, and what to do first.

This is the checklist our engineers follow when a client asks us to take over a product. It is ordered by risk, so if you only have a few days, work from the top.

Step 1: access and ownership

Before reading a line of code, confirm that the business owns and controls everything the product depends on. More takeovers stall here than anywhere else.

Step 2: can you run it and ship it?

• Clone the repository and get the application running locally from the README alone. Write down every step that was missing.
• Deploy a trivial change, such as a copy edit, to a staging environment and then to production. If nobody knows how, that is the first finding.
• Confirm how to roll back a bad release.
• Check that a staging environment exists and is close enough to production to trust.
• Find the logs, the error tracker and the uptime monitor. If there are none, add them before changing anything else.

Step 3: security

• Secrets in the repository or in client-side code. Search the history, not only the current files.
• Authentication: password hashing, session expiry, password reset flow, rate limiting on login.
• Authorisation: for a sample of endpoints, sign in as one user and request another user's records. Broken access control is the most common serious finding.
• Database exposure: is the database reachable from the internet, and are row level security policies switched on where the platform relies on them?
• Input handling: injection, file uploads, and redirects.
• Dependencies with known vulnerabilities, using the package manager's audit command.
• Admin panels and debug endpoints left open.

Step 4: data

• Backups: do they exist, where are they, and has anyone restored one? An untested backup is a hope.
• Schema: are migrations in the repository, and do they reproduce the production schema?
• Integrity: foreign keys, unique constraints and indexes on the columns queries filter by.
• Personal data: what is collected, where it is stored, and whether that matches the privacy policy.
• Growth: the largest tables and how fast they are growing.

Step 5: code health

Step 6: infrastructure and cost

• Draw the architecture as it really is: services, databases, queues, scheduled jobs and third-party calls.
• Check whether infrastructure is defined in code or was clicked together in a console.
• Review the last three months of cloud and vendor bills for anything growing faster than usage.
• List single points of failure, including the one person who knows how deployment works.

Extra checks for AI-generated code

Products built quickly with AI app builders or coding assistants tend to share a pattern: the visible flows work, and the parts nobody prompted for are missing. Veracode's 2025 GenAI Code Security Report found that AI-generated code introduced risky security flaws in 45 percent of its tests, so these checks are worth the time.

• Database rules: tables created without row level security, or with a policy that allows everything.
• API keys for payment or AI providers shipped to the browser.
• Checks done only in the interface, with no matching check on the server.
• Payment flows that trust the browser instead of a verified webhook.
• Duplicate components and helpers generated in separate sessions that do the same job slightly differently.
• No tests, no migrations and no staging environment.

None of this means the prototype was a mistake. It proved the idea cheaply. It means the next step is engineering work, and our comparison of Lovable, Bolt and v0 explains where that line usually falls.

Refactor or rewrite?

When a rewrite is justified, do it in slices beside the running system. On the Paint Nite platform rebuild we ran sync services between the old and new platforms so features could move one at a time while ticket sales continued.

The first 30 days

1. Week 1: secure access, rotate credentials, get the app running and deployable, add error tracking and backups if missing.
2. Week 2: complete the audit and deliver a ranked risk list with effort estimates.
3. Week 3: fix the critical items, usually access control, exposed secrets and missing backups. Add tests around payments and sign-up.
4. Week 4: set up CI, a staging environment and a release routine, then resume feature work alongside a refactoring backlog.

What a good audit report contains

• A one-page summary a non-technical founder can read.
• Findings ranked critical, high, medium and low, each with evidence and a recommended fix.
• An architecture diagram of the system as it is.
• A refactor or rewrite recommendation with reasons.
• A 30-day and 90-day plan with estimates.

Our takeovers start with a one- to two-week audit, followed by a support retainer ($1.5k to $8k per month) or a dedicated team depending on how much new work is planned. See app maintenance cost for what ongoing care includes.

Sources

• OWASP Top 10, broken access control: https://owasp.org/Top10/A01_2021-Broken_Access_Control/
• OWASP Application Security Verification Standard: https://owasp.org/www-project-application-security-verification-standard/
• Veracode, 2025 GenAI Code Security Report: https://www.veracode.com/resources/analyst-reports/2025-genai-code-security-report/
• Innovation Insight case study: Paint Nite platform rebuild