Code Audit Checklist: What to Review Before Launch or Fundraise

You're about to launch. Or you're about to raise. Either way, you need to know: is your code ready?

This checklist covers what experienced engineers and investors look for when evaluating a codebase. Use it to audit yourself before someone else does.

Security Checklist

Security issues are deal-killers. One exposed API key or SQL injection vulnerability can tank a fundraise or cause a breach. Check these first.

Secrets and Credentials

• No hardcoded secrets in code — Search for API keys, passwords, tokens in source files
• No secrets in git history — Even if removed, they're still in the history
• .env files are gitignored — Check that .env, .env.local, etc. are in .gitignore
• No secrets in config files — Check config.js, settings.py, YAML files
• AWS keys not exposed — Search for strings starting with AKIA
• Database connection strings secured — No credentials in URLs committed to git

Authentication and Authorization

• Passwords are hashed — Using bcrypt, argon2, or scrypt (not MD5 or SHA1)
• Sessions expire appropriately — Not infinite session tokens
• Authorization checks on all protected routes — Not just authentication
• No privilege escalation paths — Users can't access admin functions
• Rate limiting on auth endpoints — Login, signup, password reset
• CSRF protection enabled — For session-based auth

Input Validation

• SQL queries are parameterized — No string concatenation with user input
• User input is sanitized — XSS protection on rendered content
• File uploads are validated — Type checking, size limits, no path traversal
• API inputs are validated — Schema validation on request bodies

Dependencies

• No known vulnerabilities — Run npm audit, pip-audit, or equivalent
• Dependencies are up to date — Especially security-critical packages
• Lock file is committed — package-lock.json, yarn.lock, Pipfile.lock
• No unnecessary dependencies — Audit for unused packages

Architecture Checklist

Investors and technical partners want to know: can this scale? Is it maintainable?

Code Organization

• Clear folder structure — Logical organization that new developers can follow
• Separation of concerns — Business logic separate from UI, data access separate from controllers
• No god files — No files over 500 lines (ideally under 300)
• Consistent patterns — Same problems solved the same way throughout the codebase
• No dead code — Remove unused functions, commented-out blocks, abandoned features

Database Design

• Schema is documented — ERD or schema documentation exists
• Indexes on frequently queried columns — Check slow query logs
• No N+1 queries — Especially in list views and reports
• Migrations are versioned — Reproducible database state
• Backup and restore tested — Not just configured, but verified

API Design

• Consistent endpoint naming — RESTful conventions or documented alternatives
• Error responses are standardized — Consistent error format across endpoints
• Pagination on list endpoints — Not returning unbounded results
• Versioning strategy exists — For when you need breaking changes

Environment Management

• Environment variables for config — Not hardcoded values
• Separate environments exist — Development, staging, production
• Different credentials per environment — Production keys not used in development
• Environment parity — Staging mirrors production

Testing Checklist

No tests = no safety net. Every change is a risk.

Test Coverage

• Tests exist — Any tests are better than no tests
• Critical paths are tested — Authentication, payments, core features
• Tests actually run — In CI/CD, not just locally
• Tests pass — Sounds obvious, but check

Test Quality

• Tests test behavior, not implementation — Will survive refactoring
• Edge cases covered — Empty inputs, nulls, boundaries
• Error cases covered — What happens when things fail?
• Tests are maintainable — Not brittle, not flaky

CI/CD Pipeline

• Automated tests on PR — Tests run before merge
• Linting enforced — Code style is consistent
• Build verification — Code compiles/bundles successfully
• Security scanning in pipeline — Dependency audit, secret detection

Documentation Checklist

Can a new developer get productive in a day? Can you onboard a technical advisor?

Repository Documentation

• README exists and is current — Setup instructions that actually work
• Architecture overview — High-level diagram or description
• Environment setup documented — How to run locally
• Deployment process documented — How to ship to production

Code Documentation

• Complex logic is commented — Why, not what
• API endpoints documented — Parameters, responses, errors
• Database schema documented — What each table/collection stores
• Configuration options documented — What each env var does

Institutional Knowledge

• Decision log exists — Why major choices were made
• Known issues documented — Workarounds and gotchas
• Third-party integrations documented — How to get API keys, configure webhooks

Code Quality Checklist

Is this code maintainable? Can it evolve?

Readability

• Consistent naming conventions — Variables, functions, files
• Functions do one thing — Single responsibility
• No magic numbers — Constants are named and explained
• Error messages are helpful — Actionable, not cryptic

Maintainability

• DRY principle followed — No copy-paste code
• Dependencies are injected — For testability
• Configuration is externalized — Easy to change without code changes
• Logging exists — Can debug production issues

Type Safety (if applicable)

• TypeScript strict mode — For JS/TS projects
• Type definitions complete — No any escape hatches everywhere
• API types match backend — Frontend and backend agree on shapes

Performance Checklist

Will this survive success?

Database Performance

• Queries are optimized — No full table scans on large tables
• Connection pooling configured — Not opening new connections per request
• Caching strategy exists — For expensive queries

Application Performance

• No memory leaks — Long-running processes don't grow unbounded
• Async operations don't block — No synchronous waits in request handlers
• Assets are optimized — Images compressed, JS/CSS minified

Scalability

• Stateless where possible — Can run multiple instances
• External session storage — Sessions not stored in memory
• Background jobs for heavy work — Not blocking HTTP requests

Pre-Fundraise Checklist

Additional items specifically for investor due diligence:

Optics

• Git history is clean — No embarrassing commit messages
• No personal or sensitive data in repo — Customer data, internal discussions
• License files are correct — You have rights to use all code
• No TODO comments saying "fix before launch" — Clean up or resolve

Metrics

• Can articulate technical debt — Know where it is and why
• Can explain architecture decisions — Trade-offs and reasoning
• Can discuss scaling strategy — What breaks at 10x, 100x users
• Can estimate costs — Infrastructure, third-party services

Risk Assessment

• Single points of failure identified — What breaks everything?
• Bus factor > 1 — Multiple people understand critical systems
• Recovery procedures exist — What happens after an outage?

How to Use This Checklist

For Pre-Launch

1. Start with security — Breaches are unrecoverable
2. Then testing — Ship with confidence
3. Then documentation — Future you will thank you
4. Architecture and code quality — Nice to have, can iterate

For Pre-Fundraise

1. Security first — Deal-killer if wrong
2. Architecture second — Investors want to know it scales
3. Documentation third — Shows maturity
4. Everything else — Demonstrates thoroughness

For Ongoing Maintenance

Run through this checklist quarterly. Technical debt accumulates silently. Regular audits catch problems early.

Frequently Asked Questions

How long should a code audit take?

For a typical startup codebase (50K-200K lines), a thorough manual audit takes 1-2 days. An automated scan can cover 80% in minutes, with manual review for the remaining 20%.

What if we fail most of this checklist?

That's normal for early-stage startups. The goal isn't perfection. It's knowing where you stand and having a plan. Prioritize security, then work down the list.

Should we hire someone to do this?

For fundraising, an external audit adds credibility. For ongoing maintenance, build internal capability. Automated tools can reduce the need for expensive consultants.

What's the minimum viable audit?

Security scan (especially secrets), test coverage check, and dependency audit. These catch the highest-risk issues with the least effort.

You don't need to check every box before launching or raising. But you do need to know which boxes are unchecked and why.

The best founders don't hide from technical reality. They understand it, prioritize it, and communicate it clearly.

Know your code. Know your risks. Know your plan.

Related reading:

• What Do Investors Look for in a Code Audit?: The specific criteria investors evaluate
• Technical Due Diligence: What Investors Check in Your Code: The investor perspective on code audits
• I Just Inherited a Codebase. Now What?: First steps when taking over unfamiliar code
• Find Exposed Secrets in GitHub: Deep dive on the #1 security issue