AL+

Production-readiness checklist for AI-generated applications

Thirty concrete checks that separate a working AI-generated (vibe-coded) prototype from production software: security, data, failure handling, operations, coherence, dependencies, and ownership.

·

An AI-generated application is production-ready when it can serve strangers, survive failure, protect its data, and be changed by someone who understands it. Most vibe-coded prototypes meet none of these conditions, and their builders cannot tell, because a demo with one honest user never exercises them.

This checklist is the set of criteria AL+ checks when productionizing an AI-generated application. It applies equally to a prototype built by hand. Each item is verifiable; do not accept a "probably".

Security: does it protect data from anyone but its owner?

  1. Every authorization decision is enforced on the server. Hiding a button in the interface is not authorization.
  2. Database access rules (row-level security or the equivalent) are enabled and tested with a second account.
  3. No secret, API key, or password is in the source code or in the repository history.
  4. User input is validated and parameterized before it reaches the database, the file system, or a shell.
  5. Administrative routes, debug modes, and sample accounts are removed or locked.
  6. Rate limiting exists on login, signup, password reset, and any endpoint that costs money to call.
  7. Access to production (hosting, database, secrets) is individual, minimal, and revocable.

Data: can it be lost, and can it be recovered?

  1. Backups run automatically, and one has been restored to a separate environment and checked.
  2. Each kind of data has one home. The same fact is not stored in two tables or two services that can disagree.
  3. Schema changes are migrations under version control, not edits made in a database console.
  4. Personal data held is listed, with a reason for holding it and a way to delete it on request.
  5. The free tier, quota, or plan the data lives on is known, along with what happens when it is exceeded.

Failure: what happens when something goes wrong?

  1. A failed external call produces a message the user can act on, not a blank screen.
  2. Errors are recorded somewhere a human will see them, with enough context to reproduce them.
  3. Timeouts and retries are deliberate; a slow third party cannot hang the whole application.
  4. Background jobs that fail are visible, and a job that silently stops running raises an alert.
  5. Someone is notified when the application is down, by a channel they actually read.

Operations: can it be run by someone other than its author?

  1. Deployment is repeatable from the repository, by script or pipeline, not by hand.
  2. A deployment can be rolled back, and the rollback has been rehearsed once.
  3. A staging environment exists that resembles production closely enough to catch mistakes.
  4. Configuration is separate from code and documented, including every environment variable.
  5. There is a written page covering how to deploy, roll back, restore, and whom to call at each provider.

Coherence: can it be changed without breaking something unrelated?

  1. There is one way to do each common thing (fetch data, handle auth, call an API), not three generated variations.
  2. The parts that matter most (payments, permissions, data changes) have automated tests that run before deployment.
  3. Someone can explain, in plain sentences, how a request travels through the system and where its data ends up.
  4. Dead code, unused dependencies, and abandoned experiments have been removed.

Dependencies: will it still build next year?

  1. Runtime, framework, and major libraries are on supported versions with known end-of-life dates.
  2. Dependencies with known vulnerabilities have been upgraded or replaced.
  3. The project builds from a clean checkout on a machine that is not the author's.

Ownership: who answers for it?

  1. One named person or team is responsible for the application in production and has the access, knowledge, and time to act.

How to read the result

The count matters less than the pattern. A prototype that fails items 1 to 7 is not ready for a single external user, whatever else is true. One that fails only items 23 to 29 is safe to run but expensive to change, which is a problem you can schedule.

We check all thirty before taking responsibility for an application, and we keep what already works: the goal is production readiness, not a rewrite. The service page describes how; the longer argument is in AI-built software still needs an engineer.