A vibe-coded app often works the first time you run it. That is the trap. The agent built the happy path, you clicked through it, and the demo looked right. The failures show up later: on a colleague's laptop, after a restart, or the first time someone types something unexpected.
These ten checks close most of that gap. None of them is exotic. Each one catches a failure that is common in agent-written code.
1. It starts from a clean clone
Clone the repository into a fresh folder, install dependencies, and run the start command. If it fails, the app depends on something on your machine that is not in the repository: a global tool, an unpinned version, or a file you never committed.
2. The lockfile matches the manifest
Run the clean install command your CI uses, not your local shortcut. A lockfile that is out of step with the manifest passes on your laptop and fails in CI. Agents edit manifests often and do not always regenerate the lockfile.
3. Secrets are not in the code
Search the diff for keys, tokens, and connection strings. Agents sometimes copy a value from an example file into real code. Move every secret to the environment, and confirm that the environment file is ignored by git.
4. Every external call has a timeout
A request to a database or another service with no timeout will wait forever when that service stalls. Check each outbound call for an explicit timeout, and check what the app shows the user when the call fails.
5. Bad input gets a clear error
Send an empty field, a number where text should go, and a value far outside the expected range. The app should reject the input with a message a user can act on, not crash or return a blank page.
6. The database is started before the code that needs it
Startup order is a common blind spot. If the API starts before the database accepts connections, the first request fails in a confusing way. Declare the dependency, and wait for readiness before the service starts. In TDK CLI, the migration runs in its own migrator resource, ordered after Postgres and before the API, and tdk doctor warns when a service runs a migration from its own start script.
7. Migrations run once, in order
A migration in the application's startup path runs on every restart, and a second instance can run it at the same time as the first. Move migrations into a separate step that runs once before the application starts.
8. The health check reports readiness
A health route that always returns 200 tells you the process is alive, not that the service can do its job. Make the check reflect what the service needs, and keep it cheap enough to run often.
9. Generated files are not hand-edited
If a tool generates your Dockerfile, routing, or build config, edit the source that produces it, not the output. A hand edit is overwritten the next time the generator runs, and the change disappears without warning. TDK CLI checks its generated files against saved snapshots before tdk up starts, so a hand edit blocks startup and names the file.
10. You can read the failure
Break something on purpose: stop the database, return an error from one route, and remove an environment variable. Read the log each time. If the message does not say what failed and where, add the detail before the app is shared.
Before the demo
Run through the list once. Most vibe-coded projects pass the first three checks easily and fail on the last few. The fixes are usually small, and each one saves a conversation with someone who cannot start the app.
Once the checks pass, the app is ready to show someone else. That is when it begins to be a product.
Top comments (3)
The clean clone check is one I'd never have thought of, and it's easy to try. A fresh folder, install, and run quickly shows whether the app depends on something only on your machine. For a beginner who only has time for two or three of these, which would you do first?
its easy just try it
how to details github.com/tdk-landscape/tdk-cli-core