What should you check before shipping something you vibe coded?

Before you ship anything an AI helped you build, check ten things: no secret key is hardcoded or sent to the browser, anything not meant to be public actually requires the right login on the server, not just a hidden button, user input is validated instead of trusted, failures show up somewhere instead of failing silently, any paid API call has a hard spending ceiling, your dependencies are packages that actually exist and get maintained, you have a backup and rollback path you have tested, something is watching for errors after you stop watching, you have personally walked through the main user flow like a stranger would, and you can explain in plain English what the AI actually built. Skip any one of these and you have not shipped a product, you have shipped a demo with a login page. Vibe coding with confidence is doing this checklist on purpose, not hoping the AI already handled it.

I'm Mahmoud Zalt, an independent senior AI systems architect who has been building and shipping production software since 2010, sixteen years now. I run Sista AI (sistava.com), where autonomous AI agents handle real work for real customers, not a demo environment. I have gone through enough vibe-coded projects, my own included, to know exactly which corners get cut under deadline pressure and which ones turn into an incident three weeks after launch. This checklist comes from those corners, not from a generic list assembled by someone who was never on call for the result.

The 10 items, at a glance

Here is the full list before the detail. Each one takes an afternoon at most to check. Skipping one does not save you that afternoon, it just moves the cost to after launch, when it is more expensive and more public.

Secrets and access: who can see what they should not

These two are grouped together because they lead to the same failure: something private becomes public, and you find out from someone else.

1. No secret key lives in code the browser can read

AI coding tools default to whatever gets the feature working fastest, and the fastest path is usually pasting the API key straight into the code that calls it, including code that ships to the browser. It works perfectly in the demo. Independent research on AI-generated code keeps finding this at scale: one widely cited 2025 industry study, testing output across more than a hundred models, found that roughly 45 percent of the generated code introduced a real security weakness, and separate research scanning live sites built with AI tools found that something like one in five exposed at least one working API key or credential in the public source. The fix is not complicated. Keys belong in server-side environment variables that never ship to the client, and any environment file needs to be in your gitignore before your first commit, not after your first leak.

2. Anything private is checked on the server, not just hidden in the interface

Hiding an admin button from users who are not admins is a design choice, not access control. Real access control checks who is asking on the server, every time, for every request, regardless of what the interface shows them. A common vibe-coded pattern is an app that looks correctly locked down because the screen matches your role, while the underlying API will happily return anyone's data to anyone who calls it directly with a different ID. This exact pattern, dashboards and records reachable by simply changing a URL or an ID because nothing was verified server-side, has shown up often enough in AI-built apps that security researchers now treat it as the default assumption until proven otherwise.

What happens when reality does not match the demo

You tested the app with your own data, typed carefully, in the order you built it. A real user will not do that, and these two checks are about what happens when they do not.

3. Input is validated, not trusted

This is the literal meaning of "breaks on the second user." The first user is you, and you unconsciously avoid every edge you did not build. The second user pastes an email with a typo, uploads a file twice the size you expected, submits a form with a field empty, or enters something that looks like code. If the app assumes input arrives clean and shaped exactly like your test data, one of those ordinary mistakes crashes the page or, worse, corrupts a record other users depend on. Validation is not a nice-to-have layer, it is the difference between a bug report and an outage.

4. Failures show up instead of disappearing

AI-generated code has a habit of wrapping risky operations in error handling that exists only to stop the error from crashing the demo, not to actually deal with it. A catch block that logs nothing and shows the user a generic success message is worse than no error handling at all, because now the failure is invisible on both ends. A payment that silently does not go through, a form save that silently does not save, a webhook that silently never fires: these are the failures that do not show up in testing, because testing is short and users are patient right up until they are not. Errors need to go somewhere a human will actually see them.

The bill, and the code you did not write yourself

Two more things quietly slip through, because neither one affects whether the demo looks like it works.

5. A hard ceiling on anything that costs money per call

Every call to a paid API, an LLM, an image generator, a transcription service, costs something, and AI-generated integration code almost never adds a spending cap on its own, because a cap is not needed to make the feature work once, in a demo, for you. Production is a different story: a retry loop with a bug, a bot hitting an unauthenticated endpoint that happens to trigger a paid call, or simply more real usage than you budgeted for, and the bill that shows up days later is a multiple of what you planned. The fix takes minutes: hard usage caps at the provider level, rate limits on your own endpoints, and alerts before you hit either one, not after.

6. Dependencies and packages are sane

AI tools reach for a package to solve almost anything, and they are not always reaching for a real, maintained one. Models sometimes recommend packages that do not exist, and attackers have started registering those exact hallucinated names on public package registries, so that whoever installs them gets malware instead of a library, a technique researchers now call slopsquatting. Before you ship, open your dependency file and actually look: is every package one you recognize or can verify, is it still maintained, and does your app really need all of them. A handful of unfamiliar names sitting in your dependency list is not paranoia to check, it is the software supply chain equivalent of a door you never looked at to see if it was locked.

Can you see it, and can you undo it

7. A backup and rollback path you have actually tested

In one widely reported 2025 case, a founder running an AI coding agent against a live database gave it an explicit, capitalized instruction not to touch production. The agent ignored it, deleted real records belonging to well over a thousand companies, and initially told the founder the data could not be recovered at all, when a rollback actually existed and the data was eventually restored manually. The lesson is not "never trust an AI agent," it is "do not find out whether your rollback works during the incident." Back up your database on a schedule, actually run a test restore before launch, and keep your production data behind a system your AI tools cannot reach with a single approved prompt, especially once real users are on it.

8. Something is watching after you stop watching

Once you ship, you are not staring at the app anymore, your users are, and you find out about problems only if something tells you. Without basic error tracking or logging, the default way you learn something broke is an angry email, or silence, which is worse, because it means someone hit a wall and just left. This does not need to be sophisticated. A free error-tracking tool wired into your app, or even a log you actually check, closes the gap between broken for an hour and broken for two weeks with nobody knowing.

Walk through it yourself, like a stranger would

Item 9 is the cheapest check on this entire list and the most skipped. Before you ship, sit down, open a fresh browser session with no saved logins or autofill, and go through your main flow exactly the way a new visitor would: sign up with an email you have never used, enter data the way a distracted person would, click the back button mid-flow, refresh the page halfway through, submit the form twice. AI coding tools test the happy path they just wrote, in the order they wrote it, and so do you if you only click through as the person who built it. A signup flow that passes a hundred of your own tests can still fail for someone using an email with a plus sign in it, or a password manager that autofills a field the form never expected. Those are exactly the edges a real stranger finds in the first five minutes, on launch day, in front of the one person you most wanted to impress.

Do you actually understand what the AI built

The last check is the hardest, because it is not a task, it is a test of comprehension. Can you explain, in plain English, what your app actually does: where data is stored, what calls what, and what a user sees when each of the other nine things on this list fails. If you cannot answer that, you cannot debug the app when something breaks, you cannot safely ask an AI to change one part without risking another, and you cannot tell a cofounder, an investor, or a customer what happens to their data with any real confidence. This is not about learning to code from scratch. It is about being able to describe your own system out loud without guessing.

If you get through this checklist and find more gaps than you are comfortable closing on your own, that is the exact moment to get a second, experienced set of eyes on it before you launch rather than after. That kind of pre-launch review, architecture included, is a lot of what I do through AI consulting, and a few hours of it is reliably cheaper than the incident it prevents.

Frequently Asked Questions

Do I need to complete all 10 checks for a small side project?

Scale the effort to the stakes. If it is a private tool only you use, with no real user data and no paid API calls, most of this list is optional. The moment a stranger can sign up, enter their own data, or trigger something that costs you money, all ten checks matter, no matter how small the project feels.

How long does this checklist actually take?

For a small app, usually an afternoon, less if you built carefully in the first place. It takes longer if the checklist turns up a real gap, which is exactly the point: finding a missing auth check in an afternoon is a fix, finding it after launch is an incident.

Can the AI just do this checklist for me?

Partially. You can and should ask it directly: where are secrets exposed here, what happens if this API call fails, is this endpoint checking who is asking. It will catch some real issues. It will also miss the same category of thing it missed while writing the code the first time, so a human still needs to make the final call, especially on access control and architecture.

What is the single most common thing people skip?

Secrets and access control, by a wide margin. It is also the one with the most documented damage: independent research has repeatedly found hardcoded API keys and missing server-side checks across a large share of AI-built apps, and it is usually the first thing an attacker looks for, not the hundredth.

Is vibe coding actually safe for something real, like a paying product?

Yes, if you treat shipping as a deliberate second phase and not an afterthought. The building part is genuinely faster now, and often good enough. What makes it safe for real users is a checklist like this one, done on purpose before launch, not the vibe coding itself.

What should I fix first if this checklist reveals real problems?

Secrets and access control first, always, because those are the ones strangers can exploit without you ever noticing. Cost limits and backups next, because those decide how bad an incident gets. Everything else on the list you can often ship and improve in the first weeks, as long as someone is actually watching for it.

The honest tradeoff

This checklist will slow you down by an afternoon right when you are closest to shipping, and that will feel like friction you do not need. It is not. Skipping it does not remove the risk, it just moves the risk to after real people are depending on you, where it costs more, in money, trust, or both, to fix. Vibe coding with confidence is not about writing code more slowly, it is about spending a few focused hours on these ten checks before your project stops being a demo and starts being someone's Tuesday.

If you want the fuller path, from planning and building through the hardening and operating work this checklist only starts, I put the whole thing in one place, and the first half is free. Read the free handbook ->