Vibe-Coding Isn't Free: A Production Checklist for AI-Built Apps

A medical professional I read about this week built a patient management system with an AI coding agent, uploaded real patient records, and shipped it live on the public internet. Within thirty minutes of someone looking at it, the entire database was one curl command away from a stranger on the other side of the world. Voice recordings from patient consultations were flowing into a US-based API with no data processing agreement. The whole thing was stitched together through weeks of natural-language prompts with no idea what the generated code was actually doing.

That story isn't about a bad clinician. It's about what happens when a tool gets too comfortable. AI coding agents are shockingly good at making something that looks like a working app. They are not good at telling you what's missing. If you don't already know what to ask for, you won't ask for it — and the agent will not stop you.

I build custom software for businesses for a living, and I use AI coding agents every day. This isn't an argument against them. It's a short checklist for founders shipping AI-built software who don't want to end up as someone else's cautionary blog post.

1. Auth at the database, not just the front end

The first failure in every vibe-coding horror story is the same: the login page works, so the founder assumes the app is secure. It isn't. Real access control lives at the database layer — row-level policies that reject a query from a user who doesn't own the row, even if the front end thinks they do.

Ask your agent this, literally: "Show me the row-level security policies on every table in this database. If there are none, add them and explain what they do." If the answer is a shrug, the app is one curl away from leaking.

2. Know where your users' data physically lives

Every third-party service your app calls is a place your users' data ends up. Transcription APIs, embedding APIs, image hosts, email providers. For each one, you need to answer three questions: Which country are the servers in? Is data encrypted at rest? Is there a Data Processing Agreement on file?

If you are working with health, legal, financial, or children's data and any answer is "I don't know," stop. The answer is not going to become "yes" on its own.

3. The one-curl test

Open your terminal. Pick a user account. Run curl against every API endpoint in your app without logging in, or logging in as a different user. Can you read anything you shouldn't? Edit anything? Delete anything?

AI-generated backends often return the full record on a GET even when the front end is only rendering a subset. The browser filters the view; the API does not. You will find this bug on the first try, or you will learn about it from a stranger on a forum.

4. Secrets that don't leak

Your agent probably wrote DATABASE_URL=postgres://... into a config file somewhere. Grep your repo for anything that looks like a key, a token, a URL with a password in it, or a service-role secret. Check the git history. Check the client bundle — open DevTools, go to the Network tab, reload the page, and scan the JavaScript for anything that starts with sk_, eyJ, or AIza. Anything shipped to the browser is public forever.

5. What a failed login reveals

When a user types the wrong password, does your app say "wrong password" or "wrong email or password"? The first one tells an attacker which emails are real users. The second one doesn't. The AI agent will almost always generate the first version because it is "more helpful." It is also an enumeration attack vector.

This is a one-line fix. Ask your agent to make it consistent: the response for "no such user" and "wrong password" must be identical, down to the timing.

6. Logs that don't become a second breach

Logs are the thing you fix last and also the thing attackers read first. Your AI-built app is probably logging full request bodies somewhere — including passwords and session tokens. Ask: "What fields am I currently logging? Redact any of these that could appear in an auth request: password, token, authorization, cookie, ssn, card." Then check. Logging "works", so the agent won't flag it.

7. A rollback plan that exists before you need one

What happens if you ship a bad update at 11 pm on a Friday? Do you know which git commit was running an hour ago? Can you redeploy it in one command? If your answer involves "I'll figure it out," your answer is a four-hour outage waiting to happen.

Vercel, Railway, Netlify — all of them give you one-click rollback to a previous deploy. Find the button before you need it. Screenshot the URL. Send it to yourself.

The bigger pattern

None of these seven items are hard. None of them require deep engineering chops. They're the kind of thing a senior developer running in the back of your head would catch on a casual glance. The problem is that when you're shipping fast with an AI agent, there is no senior developer in the back of your head — you have a tool that says "yes" to everything and a deadline that says "now".

If the post-AI skill for founders is anything, it's building a better internal checklist. AI agents are a force multiplier in both directions. They multiply good instincts and they multiply bad ones. The seven items above are the minimum set of good instincts I look for before I let any of my own AI-built code touch real users.

If you're building something AI-assisted and you want a second set of eyes before it goes live, book a free 30-minute review or email contact@abhijitai.in. Half the reviews I do take less than an hour. The other half take a weekend. Either way, it's cheaper than explaining to your users why their data just ended up on a forum.

Also worth reading: RAG That Ships: Beyond the Demo — the same "demo vs production" gap, but for retrieval systems.