Bookmark This: The 10-Point Pre-Launch Checklist for Vibe-Coded Apps

Save this one. Run it before you show your vibe-coded app to anyone, and again before every release. Each item is a check an agent will not do for you, because it does not know the check exists.

Before you start

• [ ] Clean clone. Clone into an empty folder, install, and run. Anything that only works on your machine is a dependency you have not declared.
• [ ] Clean install matches CI. Run the same install command your pipeline runs. A lockfile out of step with the manifest passes locally and fails in CI.

Security

• [ ] No secrets in the diff. Search for keys, tokens, and connection strings. Move every value to the environment, and confirm the environment file is git-ignored.
• [ ] Scanner runs in CI. A secret scanner such as Gitleaks catches what a human misses. Treat a finding as a failed build.

Behaviour

• [ ] Timeouts on every outbound call. A call with no limit waits forever when the other side stalls.
• [ ] Bad input gets a clear answer. Try an empty field, text where a number belongs, and an oversized value. Expect a readable message, not a crash.

Services and data

• [ ] Dependencies start first. The database and any broker must be ready before the API. Declare the order rather than hoping for it. In TDK CLI, dependsOn in service.json sets it, and tdk up main --dry-run shows the start order without starting anything.
• [ ] Migrations run once, in their own step. A migration in the app's startup path runs on every restart. In TDK CLI, migrations belong in a migrator resource ordered after Postgres and before the API. tdk doctor warns when a service runs a migration from its own start script.
• [ ] Generated files are not hand-edited. Edit the source that produces a Dockerfile or routing config, then regenerate. TDK CLI checks its generated files against saved snapshots, so a hand edit blocks tdk up and names the file.

Health

• [ ] Health check reports readiness. A route that always returns 200 says the process is alive, not that the service works. Check what the service needs, and keep the check cheap.

Before the demo

Run the stack with tdk doctor --json to confirm the machine can run it, then tdk up. Watch tdk status --json until readiness is true. If something fails, read tdk logs --json --service <name> --tail 200 for the first error, not the last.

Print it

Pin this to the top of the repo, or paste it into the pull request template. The checks are short. Skipping them is how a demo becomes an incident.

TDK CLI is for local development. Production deployment stays with your existing tools, such as Helm, Argo CD, or Kustomize.