What do you check before putting a vibe-coded app in front of real users?
Genuine question for people shipping with Lovable, Bolt, v0 or Cursor. Building fast is the whole point, but the same few problems keep showing up on freshly shipped apps when you look at them from the outside: admin or debug routes left reachable, API endpoints that return another user's data if you change an ID in the URL, Supabase or Firebase tables readable without logging in, and API keys sitting in the frontend JavaScript. None of these need a hacker to find, just someone curious with a browser. So how do you handle it? Do you have a checklist before launch, rely on the platform's defaults, ask the AI to review its own code, or ship and fix later? And which of these has actually bitten you? Disclosure: I work on external recon at Xseth, so this is my day job, but I'd really like to hear what works for people here, with or without tools.
Replies
The agent lost context mid-task and rebuilt an existing helper under a new name two folders over. Everything compiled, but half the app used version A and half used version B, quietly diverging in production.
@konstantin_tikhaev That one is nasty because each version passes review on its own. It gets worse on the security side: if only version A got the auth check or input validation, half the app is protected and half isn't, and nothing looks broken. A cheap catch is asking the agent at the end of each session to list every new function it created, then checking for near-duplicates before release. How did you spot it in the end, a bug report or reading the code?
@syef_sid_ali_benkrief Users saw inconsistent date formatting across two different pages. Tracing the helper imports showed a duplicate file.
RLS is the one I write as the first migration before any UI exists, specifically because of the order problem. Build the table, wire up a working feature, enable RLS as a final step, and by then you have already forgotten which queries relied on the service role key bypassing it. Write the policy first and the feature has nowhere to hide an oversight, since nothing works until the policy allows it. Admin and debug routes are the other one I check by hand rather than trusting the platform, because the agent tends to leave them reachable under a predictable path once the feature that needed them is done, and a predictable path is the first thing anyone curious will try. For API keys in frontend JavaScript, the check I actually trust is grepping the built output for anything that looks like a key, not reading the source, since minification can hide a key that is obviously in plain text in the editor. None of this replaces a proper review, but all three catch the same class of mistake: something that worked in testing because the person testing it was already authorised.