Is your vibe-coded app ready for production? The honest checklist

"It works" is a demo claim. "It keeps working with a thousand strangers logged in while one of your dependencies has a bad day" is a production claim. The space between those two is where prompt-built apps get hurt, because the vibe coding loop tests the first claim constantly and the second one never.

Here's the list we run before calling a prompt-built app ready. Every item is a failure we've actually seen, not a best practice copied out of a textbook. Nothing on it takes more than an afternoon to check, and most take minutes.

Traffic

1. No database queries inside loops on the hot path. Trace your most common user action end to end. A query in a loop is an N+1 that passes every test until real data shows up.

2. Nothing on the hot path waits for a third party. If a click can't complete until Stripe or an email API answers, their worst day is now your worst day. Queue it.

3. You can do the connection-pool math. Maximum concurrent instances, times connections per instance, versus what the database actually allows. If you can't fill in those numbers, the practical answer is "it saturates during my first traffic spike," and you'll learn the numbers that day instead.

4. Anything that costs money per request has a rate limit. LLM calls, emails, SMS. Someone with a script will find the endpoint eventually. The rate limit decides whether that's a log line or an invoice.

Boundaries

5. Every reachable route has a named guard. Not "the app has auth," that isn't a route-level answer. Go route by route. And "the frontend doesn't link there" counts for nothing, because attackers don't use your frontend.

6. Webhooks verify signatures before doing anything. An endpoint that external services can POST to is an endpoint anyone can POST to. The check is about five lines. Skipping it means a stranger can mark orders as paid.

7. The client bundle contains no secrets. Grep the build output for key, secret, token. Everything in there is public, forever. Rotate whatever you find, then move the call server-side.

Failure

8. You know your single point of failure and its blast radius. Small systems always have one, and that's fine. Not knowing which component it is, or what goes down with it, is the actual problem.

9. You've restored a backup at least once. An untested backup is a hope with a cron job attached. Nothing about backups ever made a demo better, which is exactly why your assistant never set them up properly.

10. Kill a dependency locally and watch what happens. Stop Redis and reload the app. "Slower" is a pass. A white screen means the cache you added for speed quietly became a hard dependency, and now that's item one on your list.

The pattern in the list

Read the ten again and count how many live inside a single file. Almost none. It's all what-calls-what, on which path, behind which guard, leaning on which shared resource. The shape of the system, in other words, which is the one layer nobody reviewed when the assistant wrote the code.

So we built the list into the product. Arketo has your assistant map the app's real architecture, findings land on the exact component or edge they belong to, and the workspace rolls it all up into a ship-readiness verdict: a go or a no-go with the blockers named, not a score out of a hundred. Run it against your own app, or poke at the demo first.

Your users will run this checklist for you eventually. They just report the results as one-star reviews.