Bookmark It! STOP Shipping Broken Vibe Code: 10 Checks That Save Your App at 2 AM

Your demo works. Great. Now try it on a different laptop.

That is where vibe-coded apps die. The agent nailed the happy path, you clicked around, everything looked perfect, and then the first real user typed something weird, a restart wiped the state, or a teammate spent three hours trying to run it. Here are ten checks that stop that from happening.

1. Clone it into an empty folder

Fresh clone. Fresh install. Run it. If it breaks, your app depends on something living only on your machine. Find it and kill it.

2. Use the CI install, not your shortcut

Run the same clean install command your pipeline runs. A lockfile that is out of step with the manifest passes on your laptop and fails in CI, every single time.

3. Hunt the secrets

Search the diff for keys, tokens, and connection strings. Agents love copying example values into real code. Move every secret to the environment and make sure the env file is git-ignored.

4. Put a timeout on everything

An outbound call with no timeout will wait forever when the other side stalls. Give every call a limit, and check what the user sees when it fails.

5. Break the input on purpose

Send an empty field, text where a number belongs, and a value far outside the expected range. The app should answer with a message someone can act on, not a crash or a blank screen.

6. Start the database first

If the API boots before Postgres accepts connections, the first request fails in a confusing way. Declare the dependency and wait for readiness. In TDK CLI, migrations run in their 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. Migrate once, not on every restart

A migration in your app's startup path runs on every restart, and two instances can run it at the same time. Move it into a separate step that runs once, before anything else starts.

8. Make the health check honest

A route that always returns 200 tells you the process is alive, not that the service works. Check what the service actually needs, and keep the check cheap enough to run constantly.

9. Never hand-edit generated files

If a tool writes your Dockerfile or routing config, edit the source, not the output. Hand edits get wiped on the next generation, quietly. TDK CLI compares its generated files against saved snapshots before tdk up starts, so a hand edit blocks startup and names the file.

10. Break it and read the log

Stop the database. Throw an error in one route. Delete an environment variable. Every time, the log should say what failed and where. If it doesn't, fix that before anyone else sees the app.

The bottom line

Run all ten once. Most vibe-coded projects pass the first three and fall apart on the last few. The fixes are small. Skipping them costs you a weekend and a very confused teammate.

Your demo is not the product. Your demo that survives a clean clone is.