The Codebase Health Checklist

1. Deploys & Reliability

• Anyone on the team can deploy to production with a single, documented command or click.
• A failed deploy rolls back automatically or within minutes.
• There is at least one automated smoke test on the critical user flow.
• Environment variables are documented and validated at startup.
• You know within minutes when production breaks (error tracking is wired up).

2. Tests & Confidence

• The money/auth paths have automated test coverage.
• Tests run automatically on every pull request.
• A green build genuinely means it's safe to ship.
• You can refactor a core module without fear of silent breakage.

3. Security & Data

• Secrets live in environment variables, never in the repo.
• User input is validated on the server, not just the client.
• Auth and authorization are enforced on the server for every protected action.
• Database access is scoped so one user cannot read another's data.
• Dependencies are updated regularly and scanned for known vulnerabilities.

Critical review before you trust the total

A confirmed cross-user or cross-tenant data exposure, a compromised secret, or missing authorization and recovery controls needs immediate review regardless of the total number of Yes answers.

Do not treat an Unknown answer as safe. Record who will verify it, what evidence is needed, and whether work should pause until the answer is known.

4. Structure & Maintainability

• Core business logic lives in one place, not copy-pasted across files.
• A new engineer can find where a feature lives without a guided tour.
• Naming is consistent enough that you can guess file and function names.
• There is no 'do not touch' file that everyone is afraid of.
• Type errors and lint errors block the build instead of being ignored.

5. Process & Knowledge

• There is a README that actually explains how to run the project locally.
• Architecture decisions are written down somewhere, not just in one person's head.
• Work is tracked so you know what's in progress and what's blocked.
• There is a clear owner for production incidents.
• You could survive your most experienced engineer taking a two-week vacation.
• You ship improvements more often than you firefight regressions.

6. If the app was built with AI tools

Skip this section if a person wrote the code. Apps generated by Lovable, Bolt, v0, Replit, Cursor, or ChatGPT tend to fail in a specific set of ways, because those tools optimize for a working demo rather than a safe production system. Being AI-built is not a problem on its own; these seven checks are where it usually shows.

• Row Level Security is switched on for every table that holds user data, and you have tested that it actually blocks another account.
• No API key, service-role key, or database URL is readable in the browser bundle or in a NEXT_PUBLIC_ variable.
• Admin screens and internal tooling require a real permission check, not just an unlinked or hard-to-guess URL.
• Payment and webhook handlers are idempotent, so a retried event cannot charge or provision twice.
• Type checking and linting are not disabled at build time to make the deploy pass.
• Failure paths are handled, not just the happy path: an API timing out, a payment declining, a form submitted twice.
• Every auth flow the app offers actually works end to end, including password reset and email verification.

Scoring

Use the total to decide what to investigate first. Do not label the app healthy from a number alone.

Review each section's No and Unknown answers, then review the critical controls separately.

A high total does not override a critical failure or a critical Unknown.