Your demo works. Good. Now give the app to someone who did not build it.
That is where most vibe-coded projects fall apart. Not because the agent was careless, but because the demo never tested the things that only show up on a second machine, with a second person, or after a restart. Bookmark these ten checks and run them before you call the app ready.
1. The lockfile matches the manifest
Run the exact install command your CI runs, on a clean copy. Agents edit the manifest and forget to regenerate the lockfile. The result is a build that passes on your laptop and fails in the pipeline.
2. Every outbound call has a timeout
A call with no limit waits forever when the other side stalls. Give each one a deadline, and check what the user sees when it expires.
3. Errors are readable
Send an empty form, text where a number belongs, and an oversized value. The app should answer with a message a person can act on, not a stack trace or a blank screen.
4. Nothing secret is in the repo
Search the diff for keys and connection strings. Move every value to the environment. Confirm the environment file is git-ignored with git status.
5. The database starts before the code that needs it
An API that boots before its database accepts connections fails its first request in a confusing way. Declare the order. In TDK CLI, dependsOn in service.json sets it, and tdk up main --dry-run prints the start order without starting anything.
6. Migrations run once, in their own step
A migration in your app's startup runs on every restart, and two instances can run it at once. Move it to a separate step that runs before the app. TDK CLI runs migrations in a migrator resource, and tdk doctor warns when a service runs one from its start script.
7. Generated files are never hand-edited
A Dockerfile or routing file you change by hand is overwritten by the next generation, quietly. Change the source and regenerate. TDK CLI compares its generated files with saved snapshots before tdk up starts, so a hand edit stops the start and names the file.
8. The health check tells the truth
A route that returns 200 every time says the process is alive, not that the service works. Check what the service actually needs, and keep the check cheap enough to run often.
9. A teammate can start it from a clean clone
Clone into an empty folder, follow your README, and run one command. If it fails, your app depends on something that only lives on your laptop. Find it, and write it down.
10. You can read the failure
Stop the database on purpose. Throw an error in one route. Remove one environment variable. The log should say what broke and where. If it doesn't, fix that before anyone else sees the app.
The short version
Run all ten once. Most vibe-coded projects pass the first few and fail on the last few. The fixes are small, and each one saves a conversation you would rather not have.
For a multi-service app, the local stack is where most of the second-machine problems show up. With TDK CLI, start with tdk doctor --json to confirm the machine can run it, then tdk up, then tdk status --json until everything reports ready. If something fails, tdk logs --json --service <name> --tail 200 shows the first error.
Your demo is not the product. The demo that survives a clean clone and a teammate's laptop is.
Top comments (1)
cool!